[evs] Branching on commit, merge documentation

Tony Hoyle tony.hoyle at march-hare.com
Wed Sep 12 09:35:18 BST 2007

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.


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

More information about the evs mailing list