[evs] Branching on commit, merge documentation

Arthur Barrett arthur.barrett at march-hare.com
Thu Sep 6 23:04:53 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.


> One of the techniques we were talking about is what they call "cherry
> picking". I'm sure that's no strange concept to you; this is what CVSNT 
> has
> bug ids for. Say you have a number of bug fixes on a branch, and merge a

Yes exactly - we already support this, just in a way that gives more 
features, so trying to implement the monotone way would just confuse 
people...  Using the changeset id /bug id means you can then use this 
information over and over again, eg: to create release notes, to back 
changes out etc etc.

> few of them into another. Every such bug fix merge is essentially a double
> j merge (or a few of them) -- independently of whether you use a bug 
> number
> in the command or two tags with two j options. In the end, you might have
> merged the changesets between revisions 1.5 thru 1.7 and 1.11 thru 1.15
> into (for one file).

Instead of doing a double j merge, commit with a bug id and use a single j 
merge plus bugid, then only the changes represented by the changeset will be 

The latest 2.5.03 code and eventually 2.5.04 also allows messages to be 
converted to bug numbers for people using non-cvsnt clients, eg: cvs ci -m 
"bug123 is fixed".  But you don't need to wait for this, today just use cvs 
ci -B 123 -m "fixed" then do "cvs up -j HEAD -b 123"



More information about the evs mailing list