[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Tue Sep 11 15:33:54 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.

Arthur Barrett wrote:

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

The situation I was talking about (and that was a part of that thread back
then) is e.g. a feature branch off a development branch. You keep it for
some weeks developing a feature, and during that time you keep the feature
branch close to the parent branch (be it trunk or some other branch) by
regularly running single j merges, merging changes from the parent branch
to the feature branch. At the end of the feature branch, you want the
feature code to go into the parent branch. Tony proposed a double j merge
for merging the difference between the parent branch and the feature branch
into the parent branch. (Of course best used after a last single j merge
from the parent branch into the feature branch and resolving all conflicts

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

It seems that if you mark all commits on the feature branch with a bugid
and eventually merge that bugid into the parent branch, you get the same
conflicts you get with bidirectional merging, as you would essentially
merge back into the parent branch all the code from the parent branch that
has already been merged into the feature branch (and has been
conflict-solved there). 

I don't see how bugids would help in such a scenario, where you have to
keep the bug/feature development regularly updated with the changes to the
parent code.

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

This is the reason why I started this conversation here on the EVS group.
I'm fully aware that it is a big change to add such information to the RCS
files, but I thought that since the internals of the revision storage
probably are going to be somewhat redesigned anyway for EVS, you guys may
think about adding complete merge documentation to it.

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

I think it only works if the bugid commits never contain any code that has
been merged in from a branch to which you merge that bugid code later.
Which may be the case in some scenarios, especially with smaller bugs or
features, but with larger features or bugs there are often merges from the
mainline involved (to which the bugid code later would get merged) -- so it
may not be the general case.


More information about the evs mailing list