[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Thu Sep 6 13:16:02 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:

>> You seem to be talking about the single -j merge exclusively. No
>> discussion here. I'm talking about the double -j merge (for one thing)
>> and the bug number (for another thing). 
> Please give an example of when you need to use a double j merge, I
> haven't used it in 5 years.  Yes the mergepoints are exclusively for
> single j merges, but I've trained a lot of customers over the past 3
> years and none have ever needed a double j merge...

As I wrote in my original post, this all was triggered by a conversation
with a monotone user. He uses the system for some things that are not
version control proper, but seem to fit quite nicely and make sense. 

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

I think it would be quite useful to have this documented in the repository
(rather than in my merge notes), and to be able to see that when looking at
the file history. I don't see the use of having to keep a manual history of
the merges if the system can do that, based on my commands, automatically
-- more thorough and less error-prone. 


More information about the evs mailing list