[cvsnt] Mergepoint issues on 220.127.116.11 b2382
lists at connectionbrazil.com
Wed Jan 10 16:38:53 GMT 2007
Harrison, Andy wrote:
> Since this proved to be a very simple and easy process, we took it one
> step further. Before the development branch was merged into the trunk, a
> final re-base we performed. This way all the regression testing we
> needed to do can be done on the development branch before the code went
> anywhere near the trunk.
If I understand you correctly, at this point you have in the development
branch the trunk code plus the new feature -- exactly what you want to have
on the trunk afterwards.
> This then means that the final merge into the trunk is a trivial affair.
Your problem seems to be that you merge this code back into the trunk, when
there is no need for a merge. The code on the branch as it is after the
last merge from the trunk is what you want to have on the trunk -- if you
have done the merges from the trunk to the branch correctly. (If not, you
need to find these problems either way.) So a move of the code on the
branch to the trunk should do it; there's no need for a merge.
AFAIK this code move is not directly supported by cvsnt, but the earlier
thread Tony E mentioned showed some solutions for this close to its end.
> Please can you explain to be exactly how this (or another scenario)
> might result in lost data?
If you look at merging in terms of deltas between revisions and try to
write down the delta handling for a simple case of back-and-forth merging
like you described (don't forget to include some manual conflict
resolution), you see that this is non-trivial even for simple cases. That's
basically the reason why it's better to merge in one direction, end up with
the final code in the branch you are merging to, and then move this code to
where it belongs. Can you describe in how this would be different from your
current process (result-wise)?
More information about the cvsnt