[evs] Branching on commit, merge documentation

Arthur Barrett arthur.barrett at march-hare.com
Tue Sep 11 15:54:00 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.


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

Err yes - my example was backwards.  So when you make "real" changes to the 
branch then you use unique bug ids, and you then merge those bug id's down 
to the trunk, which obviously don't exist there... But that is potentially 
more than just a single merge, since there may be 20 or 30 or any number of 

Back when this was frist described I had never heard of it being needed, and 
I still am in the same boat.  If a bug is found on the branch that is 
applicable to the trunk then that bug is applied down to the trunk at the 
time (either by merge -j branch -B bug or by recoding), not some arbitrary 
point later...

But I understand you are describing a process that works for you - I can't 
help myself suspecting that if changesets were used more then a change a 
little here and a little there to the process and most of this "problem" 
would go away.

Suggesting a double j mergepoint for EVS now we have all the details makes 
sense I think, but I still remain sceptical that you'd really do things that 
way if you were using changesets...  Or if not maybe changesets need to 
support this process better...



More information about the evs mailing list