[cvsnt] Re: 2.0.58d/mergepoints

[Tony Hoyle]

David Hauck wrote:
> Hi Tony,
> 
> I'm currently using the 2.0.58d cvsnt client and server and would like to
> leverage its support for mergepoints. Are there any caveats associated with
> this feature in 2.0.58d that you might alert me to?

IIRC there was an issue with empty branches in that version but it's 
rare to come across it.

> In particular, this time I'd like to leverage the CVSNT mergpoint support in
> order to eliminate the need to specify a common ancestor for the merge. I'll
> be merging from the HEAD into a first-level branch and could like to perform
> this with something like: cvs -q up -k-v -j HEAD. Ideally I'd like to merge
> the head into branch with a fixed tag on the head, but some documentation
> I've seen says that this wouldn't work correctly for merging added/removed
> files. Is this accurate?

There's an ambiguity with merging for removed files (added files are OK, 
normally, since any conflict can be handled in-place).  eg. if you're 
merging branch A onto branch B, and branch A has changes since the last 
merge, but branch B has a remove, then it's a conflict on the whole 
file, which requires intervention (you need to work out whether the 
changes in that file should be kept, copied elsewhere, etc.).

cvs will warn you if/when this happens.

> Another aspect of the branch is that it (branch #1) has previously been
> received several merges from another branch (branch #2); this other branch
> (#2) has also been merged into the head, but this will be the first time the
> head is merged into branch #1. I'm hoping the use of mergepoints will
> prevent problems related to conflicts associated with brach #2 being merged
> into both branch #1 and the head, prior to the head being merged into branch
> #1.
> 
A mergepoint is basically point where you say 'for this version Branch A 
== Branch B', and this works both ways.. eg. if you merge a->b, commit, 
then b->a, there won't be anything to merge.

This works well for 2 branches.  For 3 you might have more issue, 
depending on the merge history...  with a little planning you should be 
able to reduce or even remove conflicts from your merges.

Tony