Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Sun, 14 Jan 2007 13:27:28 +0000, Gerhard Fiedler wrote:
...
> I agree with this. I'm only talking about what we both seem to consider a
> "correct" merge (one that deserves a merge arrow, one that completely
> integrates functionality from both code lines).
Ok. :-)
....
> > Now we are going to do it your way. We merge into the branch again
> > and then copy the branch into the head:
> >
> > (1.3 1.1.2.4 Branch and head evolve further)
> > | |
> > +-----> 1.1.2.5 Get more features into branch
> > | |
> > 1.4 <=======X Do copy outside cvsnt.
> > |
> >
> > For the merge we merge the diff from 1.2 to 1.3 into 1.1.2.4, yielding
> > 1.1.2.5 which we then copy as 1.4 onto the head.
> >
> > Now, if we are doing it my way (patched cvsnt), then we simply do
> > a backmerge:
> >
> > (1.3 1.1.2.4 Branch and head evolve further)
> > | |
> > 1.4 <-------+ Merge back into head, using patch
> > | |
> >
> > This backmerge goes to merge the diff from 1.2 to 1.1.2.4 into 1.3,
> > again yielding 1.4.
>
> How does this continue? (Below you said that one of the differences between
> the merge-back-and-forth approach and the merge-forth-copy-back approach is
> that the branch can or can't be used...)
Basically, the existing merge arrows correctly describe the deeds done
so far. So future merges in either direction will to the right thing
(assuming the patch, of course).
In contrast, with the copy-back operation cvsnt does not know
about that transfer, and will do incorrect merge base selections
for future merge between the two branches.
>
> > 1.1---------+
> > | |
> > | 1.1.2.1
> > | |
> > 1.2 1.1.2.2
> > | |
> > +-----> 1.1.2.3 Get more features into branch
> > | |
> > 1.3 1.1.2.4 Branch and head evolve further
> > | |
> > 1.4 <-------+ Merge back into head, using patch
> > | |
>
> For further development on the branch, you need to get the 1.3
> functionality on the branch.
But not necessarily immediately.
> Let's also consider that the back merge
> created a number of conflicts that had to be resolved, like taking code
> out, some reorganizing and everything we agreed upon earlier that may
> happen in a merge.
>
> So, after the merge that created 1.4 (and maybe after some additional work
> on both trunk and branch), you run again a merge from trunk to branch. How
> does this work? Looks messy to me.
Not really. If you directly merge back into the branch from 1.4 (and
nothing has been done on the branch since) it actually degenerates
into a copy. Otherwise 1.1.2.4 is now the effective common ancestor,
and merges only deal with what has changed in 1.4 on the head (a lot
and potentially messy stuff from the backmerge) and what changed on
the branch since 1.1.2.4 (probably very little).
If 'messy' meant the common ancestor selection: That now is 1.1.2.4
(as by the diagram above), independent of the direction of the
next merge.
...
> > Thus, merge forward and copy back produces the *same* result
> > in the head as the merge-back-with-patch whose common
> > ancestor selection Tony declared bogus.
>
> Maybe in the head; I'm not sure. But it definitely doesn't produce the same
> result on the branch.
Right. In merge-forward-copy-back the branch is (obviously) in the same
state as the head, except that cvsnt does not know that. In merge-back
it is in its original (pre-back-merge) state, ready to receive merges
or do work on it.
...
> > The only difference is that, after the merge-forward-copy-back,
> > the branch is in a state where it can't be used anymore.
>
> Why is this? We started out considering a scenario where one has a branch
> that one wants to keep up-to-date with the trunk while implementing a
> feature on the branch. So this line, right before the copy-branch-to-trunk,
> would be necessary anyway:
>
> > +-----> 1.1.2.5 Get more features into branch
>
> After this line, the branch has all features from trunk plus the new branch
> feature. So I can copy it to the trunk, if I want the branch feature there.
> There's nothing that prevents me from continuing development on the branch,
> say to enhance the new feature.
Yes, but you can't properly merge that work into the trunk any more. Nor
can you merge new trunk stuff into the branch. The situation is:
(1.3)
+-----> 1.1.2.5 Get more features into branch
| |
1.4 <=======X Do copy outside cvsnt.
|
In 1.4 the head contains everything from the branch so far, but the
merge arrows don't record that fact.
If you do a new merge from head to branch, regular cvsnt will merge
the changes from 1.3 to 1.4 into the branch, although that is exactly
the work that already has been done in the branch. A merge from branch
to head fails anyway because regular cvsnt considers the branch root
as the common ancestor in that case. Both will lead to spurious
merge conflicts.
...
> > And the copy-back is an operation that cvsnt does not provide and has to
> > be done manually.
>
> I don't think this is correct. If you mean by "done manually" that one has
> to use a command line command, you are correct. You could use a cvs update
> command on the trunk to merge in the complete branch, from (branch) start
> to (branch) tip. (After the 1.1.2.5. merge, of course.) Something like
>
> cvs up -j tagBranchStart -j branch
>
No. After the merge to 1.1.2.5 there is no need for a merge, the branch
is in exactly the state you want the head to have (you already merged
the head with the branch). But you are right; you can use cvs to do that:
cvs up -j HEAD -j branch
If you *don't* do the merge-to-branch resulting in 1.1.2.5, then you
can do:
cvs up -j 1.2 -j branch
Your
cvs up -j tagBranchStart -j branch
will try to merge all the head/trunk changes that have been merged
into the branch (and that are *all* changes on the head) back into
the head where they already are. This gets you a lot of spurious
conflicts (which is exactly the way we noticed that cvsnt lost
the merge-arrow-controlled bidirectional merge capability).
> run on trunk does the copy-back-to-trunk. It needs a branch start tag,
> which is a good thing to have anyway.
Due to the lack of '-rbranch:BASE'. :-)
>It also can be repeated after having
> been done once, if one tags the branch at this merge (also a good thing to
> do anyway) and uses now this new tag as start reference.
It was my impression that the merge arrow business was to avoid this
bookkeeping (which gets especially nasty if you occasionally only
merge specific parts of the tree instead of the while project).
Andreas
--
np: 4'33