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.
Gerhard, > 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 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. 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" Regards, Arthur