Re: [Monotone-devel] db query error on propagate, monotone 0.16

[Nathaniel Smith]

On Wed, Jan 05, 2005 at 11:11:41AM +0100, Georg-W. Koltermann wrote:
> Well, what I meant to achieve is just to copy the habits that we are
> using in ClearCase.  We have a main branch where we fork off the
> development branch for some version of our software, say version r5.
> Development takes place on that branch until we hit a release date.  At
> that point we label the final version on the development branch and
> merge it back into the main branch, creating this topology (lines denote
> branches, "+" denote version on branch):
> 
>               +
>               |\
>         main  | +
>     (branch)  |  \ r5-features (branch)
>               |   +
>               |    \
>               |     +  R5-RELEASE (version)
>               |    / \
>               |   / 
>               + <- (merge back into main branch)
>               |\
>               | + r6-features (branch)
>               |  \
> 
> If we needed a bugfix to R5-RELEASE we could continue on the r5-features
> branch past the R5-RELEASE version, or fork off a different branch at
> that point (more likely).
> 
> There are certainly other patterns of accomplishing the same goal, this
> is just how we did it in the past, and I wanted to check if monotone
> could support the same usage.  It may be strange, but it still makes
> sense to me.

That all sounds perfectly reasonable; the only thing is that if there
have been really no changes at all on the main branch, then from
Monotone's point of view there's just no merge there to perform.
Merges have to involve different versions...

Everything you describe should work as of
  4eda564e05108d2026c0cfb77733188790eeb754
in the monotone mainline, now.

> The second challenge I wanted to test but could not get to is, what
> would happen if we actually continued fixing beyond R5-RELEASE on the
> r5-features branch and would then try to propagate a second time, this
> time to r6-features.  Semantically that would integrate the fixes of r5
> into the ongoing development of r6.  And of course the system should
> remember that at that point in time r6-features already contains all
> bits of r5-features up to R5-RELEASE, and it should not offer those
> lines for merging again.

Sure, none of this is a problem at all.  Maybe the thing to remember
is that in Monotone, "branches" are just labels we stick on some
revisions.  We never have to worry about remembering what pieces of
r5-features are in r6-features or things like that; we just find the
revisions that you want to merge, find a good common ancestor, and
merge them.  So what you want falls out for free.

> > However, propagate should still have done something useful in this
> > case.  I think what we want is, when the user does propagate B A:
> >   - if head(B) is a proper descendent of head(A), then don't perform a
> >     merge, but do add a branch A cert to head(B).
> 
> i. Should we also add an ancestor cert to indicate that the current
> head(B) is also a descendent of the old head(A)?  I think so.  

- There's no such thing as an ancestor cert, at least not since 0.15.
- They're replaced by the revision graph, which we _can't_ go back and
  modify like that, it's mathematically impossible
- But that's okay, because we don't want to go back and add redundant
  ancestry edges like that, because the information is already there
  in the graph anyway

> ii. So now we have a single version which is on more than one branch.
> Is that handled properly?  E.g. if I were to checkout that version,
> perform some edits and commit, which branch would I commit to?  Would
> monotone request that I explicitly specify --branch=...?

Yep, barring bugs, of course.  But it probably works correctly now,
and if it doesn't somehow then it's fixable.

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."