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.
Andreas Krey wrote:
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
| |
1.5 1.1.2.5 Branch and head evolve further
| |
+-----> 1.1.2.6 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 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).
Let's say there were changes in both branches (.5 in the diagram above).
> 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.
How does this "grab" the changes that happened between 1.2 and 1.3 when you
merge into the branch and create 1.1.2.6?
> 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.
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 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).
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
understood it.
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.
Gerhard