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 1.3.2.3 (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. Gerhard