[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Wed Sep 12 13:41:43 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.

Tony Hoyle wrote:

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

That was my point with bringing this up here. I think the merge points are
not enough to document what was actually merged, and as you explained, not
even me keeping a log of which bugids I merged is enough. If I merge bugid
2, I get also all enclosed revisions associated with bugid3... Without
requesting this, and without knowing it. I think the system should somehow
be able to tell me later what it actually did merge. 

Also, what if at the time of the merge of bugid 2 the work on bugid 3 was
not yet completed and in the end depends on a revision "1.8 Bug 3"? The
merge of bugid 2 includes then some incomplete and possibly only half
working bugid 3. How do you deal with this? The way Arthur describes
working with bugids, this must be quite normal. 


More information about the evs mailing list