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: > 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. Just to make this clear: I'm not talking about changing this; I think this is a very good feature. >> 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). > > 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 merged. Yes, I knew that. And it is not the merge process I'm talking about, it's the documentation of the merge: being able to run a log on a file later and see what got merged from where to where. Merge points now provide this for normal single j merges from branch to branch, but I don't think that bugid merges do (and neither do double j merges). Gerhard