[cvsnt] Mergepoint issues on 18.104.22.168 b2382
lists at connectionbrazil.com
Mon Jan 15 11:45:42 GMT 2007
Andreas Krey wrote:
+-----> 22.214.171.124 Get more features into branch
1.3 126.96.36.199 Branch and head evolve further
1.4 <-------+ Merge back into head, using patch
1.5 188.8.131.52 Branch and head evolve further
+-----> 184.108.40.206 Get more features into branch - see below
>> For further development on the branch, you need to get the 1.3
>> functionality on the branch.
> But not necessarily immediately.
I meant it was needed. Not for the merge process's sake, but because the
functionality was needed.
>> 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 220.127.116.11 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 18.104.22.168 (probably very little).
Let's say there were changes in both branches (.5 in the diagram above).
> If 'messy' meant the common ancestor selection: That now is 22.214.171.124
> (as by the diagram above), independent of the direction of the
> next merge.
How does this "grab" the changes that happened between 1.2 and 1.3 when you
merge into the branch and create 126.96.36.199?
> 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:
> +-----> 188.8.131.52 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.
You are correct, I missed this.
>>> 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 184.108.40.206. merge, of course.) Something like
>> cvs up -j tagBranchStart -j branch
> No. After the merge to 220.127.116.11 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).
Yes, you are right again... :) I actually never did it that way, I always
used a three-step approach (copy branch to trunk, add files that are new on
trunk, remove files on trunk that are not on the branch). This merge
command is what Tony H suggested, in that earlier thread, and I thought I
I wish Tony H or Arthur would explain better the situation(s) they have
seen that lead to data loss. IIRC, so far it was only a "trust me on that"
or something the like... I think it would be extremely helpful if the
situations that lead to data loss were described somewhere in a way that
allows them to be reproduced.
More information about the cvsnt