[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] problem with update after merge (was: Re: db query erro
From: |
Georg-W. Koltermann |
Subject: |
[Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16) |
Date: |
Mon, 17 Jan 2005 14:44:22 +0100 |
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.
- [Monotone-devel] db query error on propagate, monotone 0.16, Georg-W. Koltermann, 2005/01/04
- [Monotone-devel] Re: db query error on propagate, monotone 0.16, graydon hoare, 2005/01/04
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Matthew A. Nicholson, 2005/01/04
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Nathaniel Smith, 2005/01/05
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Georg-W. Koltermann, 2005/01/05
- Re: [Monotone-devel] db query error on propagate, monotone 0.16, Nathaniel Smith, 2005/01/05
- [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16),
Georg-W. Koltermann <=
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/17
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Georg-W. Koltermann, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Georg-W. Koltermann, 2005/01/21
- Re: [Monotone-devel] problem with update after merge (was: Re: db query error on propagate, monotone 0.16), Nathaniel Smith, 2005/01/21
Re: [Monotone-devel] db query error on propagate, monotone 0.16, Nathaniel Smith, 2005/01/05