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: >>> How is this different to what CVSNT already does? >> >> I don't see that CVSNT does this at all. When merging in a sequence of >> changes (that is, if you're not merging from the top of a parallel >> branch), I think there are two methods: bug ids and the update merge >> with two -j options. > > The single -j merge ... 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). The double -j merge has two points of interest (on the source branch) related to the target revision. I don't think CVSNT stores these. Similar the bug id merge; here it may even be several two-point relationships to the target revision of the merge. The business case: every merge has to be diligently documented. This costs time, and the occasionally inevitable failure to do so costs even more time later on. The version control system storing the merge commands in a format that can later be retrieved and processed (e.g. for showing merge arrows) can help here a lot. (No hard figures in terms of money or time saved, but I think it is almost obvious that this saves time.) In this category fall IMO an automatic tag on the root of every branch, and storing /all/ merge relationships (including double -j merges, and non-contiguous bug id merges) in the repository. > Yes. And I think this is a good thing not a bad thing. For instance the > Eclipse team have written some very nifty functions by using nothing but the > basic CVS 1.11 commands, it makes their Java IDE more popular than some > others. Nice, but imagine a business building its version control processes around Eclipse features based on CVSNT servers and then needing to handle files that Eclipse doesn't -- even though CVSNT would (as it does all of them). Just because they switch editors now they have to change their version control procedures. I wouldn't like that. > Recent experience shows that adding "features" to CVSNT does NOT result in > them getting added to GUI's (unless we do it ourselves), but adding low > level functions that can be combined in a number of ways is likely to get > used (eg: "cvs ls"). This may be; I'm sure you have observed this much more than I did. >>> What business problem does this solve? >> >> What business problem any of this solves -- or whether it solves a >> business > > I generally do not ask rhetorical questions. If there is no business > case March Hare wont do it. Believe me, I understand that fully. I didn't mean to "request" this feature; I just wanted to have it mentioned. When I do so, I know that you have your priorities and will take it or leave it and either is fine with me. I just think that my mentioning may have been the one thing that got something rolling that for other reasons already was somewhere noted, and in such a case it would be a shame to think that I missed that chance :) Gerhard