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, >> OK - that's a good suggestion, but there are other solutions that would >> not require coding a new feature into CVSNT (though that would be >> ideal). > > I still think it would make sense to have start and end of a double j > merge > stored somewhat similar to a merge point. You say it's a rarely used > feature, but a double j merge is exactly what Tony suggested for merging a > branch back to its ancestor -- which I wouldn't call a rare or exotic > situation. (Even though that is a special case of the double j merge, it > still is one.) I remember that conversation differently, I remember both Tony and I considering it very rare but several people all indicating that they do it and find it useful. My solution is different to Tony's - I think SCM without bugid's is a bit rubbish, so I'd always be using bug id's in which case a double j merge would not be necessary I think - though I haven't tested that particular scenario... The "problem" with providing support for a double j merge is defining new information to go into the RCS file, then getting tools like the revision graph to support it. It's all feasible, but unless a large commercial support customer requested it then it's just not going to end up on the March Hare CVSNT todo list anytime in the near future. A compromise feature would be the ability to "add" bug numbers to revisions, which I've been thinking about the need for for some time. If the bug number plus revision option works on a "backwards merge" (needs testing) then that would provide a solution within the range of information already stored in the RCS file... Regards, Arthur