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.
Gerhard Fiedler wrote: > One loosely related feature I'm dreaming about is that the system knows > what has been merged and excludes anything that has already been merged > from a future merge (unless an override option is set that advises it to > merge "literally"), for both unidirectional and bidirectional cases. > That's not really possible - each revision is dependent on the revision before it, so for example you have: 1.1 Bug 1 1.2 Bug 2 1.3 Bug 3 1.4 Bug 3 1.5 Bug 2 1.6 Bug 4 1.7 Bug 1 A merge of bug 2 for example must include every revision in between, in this case implicitly merging bug 3. Let's say you have merged bugs 2 and 4.. you can record this somewhere (mergepoint history is the wrong place though* - cvsnt has nowhere to put it.. evs could create a property with the details in it theoretically). However a subsequent final merge of the entire branch cannot 'just' merge bugs 1 and 3... the final revision of bug 1 is dependent on everything that went before it - that may not be in the target branch at all. It's a natural conflict and only humans can decide whether it's even possible for the merge to go ahead. cvsnt/evs will not conflict on 'identical' merges (it prints 'changes are already in revision' I think) but where the target as changed without knowledge of the code structure the tool can't make assumptions, so plays it safe. Tony * In theory in this case a merge of bug 1 could set the mergepoint to 1.7 as all previous revisions have been merged, but I'm not sure how easy/possible that is to detect programmatically... and it's a rather contrived example anyway.