[Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16)

[Georg-W. Koltermann]

Hi Nathaniel,

Am Mittwoch, den 05.01.2005, 02:43 -0800 schrieb 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.

Yep, confirmed as of 0b17415d7aa112060e8ead9ae7a486510dc61a9d.

There is one anomaly, though.

I have one directory with the main branch checked out, containing only
the first revision at first.

I check out that main branch to another directory, create the
r5-features branch there, and merge it back into the main branch.

Then I go back into the first directory with the main branch (prior rev)
checked out, and do a "monotone update".  Since I recently merged
r5-features into main I expect of course that the directory should be
updated to contain that merged version.  It doesn't do that, instead it
prints:

        monotone: warning: update edge 5419a30854a07e05a0a6c05f353ee9f6b80014f9
        -> b4869a21118e845b3da273aed0dc4c6ecbb0a6d4 ignored since it exits
        branch test-main
        monotone: already up to date at 5419a30854a07e05a0a6c05f353ee9f6b80014f9
        
If I checkout the main branch into a fresh directory I do get the
correct version, the problem is only with "monotone update".

Do you think that could be fixed?

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

It does indeed as my testing now shows.  Great!

...
> - There's no such thing as an ancestor cert, at least not since 0.15.

Ah, sorry, it's a while since I read the docs and I didn't follow the
0.15 changes really closely.  Thanks.

--
Regards,
Georg.