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

[Georg-W. Koltermann]

On Tue, 2005-01-04 at 21:43 -0800, Nathaniel Smith wrote:
...
> Firstly, the proximal cause of the problem is that we have a graph
> like A -> B -> C and we're trying to merge A and C.  This is
> ill-defined, and what's more, untested.
> 
...
> If we fix these, we still have a problem, in that we don't actually
> _want_ merging A and C to work.  That would create the silly graph
> A -> B -> C -> D, A -> D, which has no sensible interpretation.

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.

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.
   
> 
> 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.  

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=...?

--
Regards,
Georg.