[evs] Branching on commit, merge documentation

Arthur Barrett arthur.barrett at march-hare.com
Tue Sep 11 13:49:32 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.


>> OK - that's a good suggestion, but there are other solutions that would
>> not require coding a new feature into CVSNT (though that would be
>> ideal).
> I still think it would make sense to have start and end of a double j 
> merge
> stored somewhat similar to a merge point. You say it's a rarely used
> feature, but a double j merge is exactly what Tony suggested for merging a
> branch back to its ancestor -- which I wouldn't call a rare or exotic
> situation. (Even though that is a special case of the double j merge, it
> still is one.)

I remember that conversation differently, I remember both Tony and I 
considering it very rare but several people all indicating that they do it 
and find it useful.  My solution is different to Tony's - I think SCM 
without bugid's is a bit rubbish, so I'd always be using bug id's in which 
case a double j merge would not be necessary I think - though I haven't 
tested that particular scenario...

The "problem" with providing support for a double j merge is defining new 
information to go into the RCS file, then getting tools like the revision 
graph to support it.  It's all feasible, but unless a large commercial 
support customer requested it then it's just not going to end up on the 
March Hare CVSNT todo list anytime in the near future.  A compromise feature 
would be the ability to "add" bug numbers to revisions, which I've been 
thinking about the need for for some time.  If the bug number plus revision 
option works on a "backwards merge" (needs testing) then that would provide 
a solution within the range of information already stored in the RCS file...



More information about the evs mailing list