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.
Hi Tony, Thanks for your comments. I've come to the conclusion (after running a series of merges and comparing their results) that mergepoints don't help me with my current situation. In fact there's some pretty strange results in the mergepoint-reliant test - but I expect this is due to the various merge history events that are "tagging along" in this merge. As you mention below the two branch scenario seems to be a natural fit for mergepoints, and their use, in this case, makes merging quite straightforward. I haven't used this previously but will now look for opportunities for its use in the future. BTW, the symmetric result of the two-branch mergepoint example you describe below isn't clear to me (as I believe Gerhard is also questioning). This isn't something that I came across in the documentation, but perhaps this side effect is explicitly described somewhere else? Thanks again, -David > 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 > _______________________________________________ > cvsnt mailing list > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs