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.
Kristis, >> In particular we discovered that using "generic attributes" >> for bug numbers (such as tags) prevented us from adding >> useful features such as commit by bug number, merge by bug >> number etc. Cut > > I agree with you. But, I don't see how this is relates to >Scmbug. Scmbug permits a single change to have multiple bug >numbers. The core of my argument was as above - not simply that tags are not suitable, but that the "best" place for this in our opinion was in the repository so that CM operations like commit can take advantage of it with minimal chage to the client interfaces. The CVSNT project also tends to be monolithic - I can think of good reasons why, but I doubt if anyone ever sat down and planned to make it that way. The CVS project tends to add functions by adding "add ons" such as perl scripts. If it cannot be added on then it rarely makes it into CVS (since such changes require concensus with all the registered developers due to the CVS charter. CVSNT tends to add features into the core whilst at the same time making the core more "pluggable". Eg: in CVS you have to enable all protocols or re-build your own from source, whereas in CVSNT individual protocols can be disabled or even deleted. And in CVSNT bug numbers are a part of the core (cvs edit -b, cvs commit -b, cvs update -b), whereas in CVS you'd write a perl script like scmbug. >We provide an installation script that installs the integration >, if that's what you mean by setup. Perl scripts require perl for a start - and every company we've installed CM systems in wont allow perl on a windows server (too insecure - or at least too much work for the security people to ensure it is secure). Regards, Arthur Barrett