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.
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