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.
Bryce, > My $0.02: CVSNT, though it is open-source, has a > lock-in problem. No other SCM seems to be interested > in converting from it, so if for whatever reason, > you decide that CVSNT is not for you, and you've > actually used some of its features that give it > an advantage, you'll have a royal pain of a time > migrating to anything else (without paying someone > to do it for you. I understand that this is not > CVSNT's problem, but is a practical issue for its > users. For myself, staying with the mainstream of > SCM choices is a far safer bet. Thanks for your input - it's not an argument I've heard before. I disagree with this reasoning though both philosophically and technically. 1. The fact that there are not many CVSNT to XYZ converters is an artifact of the fact that few people want to convert from CVSNT to XYZ - it is NOT an indication of the number of people USING CVSNT (or how "mainstream" it is). There are certainly tools to convert from XYZ to ABC for much less "mainstream" software, because people don't want to use XYZ anymore. By your argument SVN is not "mainstream" because there are no SVN to ClearCase converters (or SVN to anything as far as I can tell). The availability of converters is unrelated to how "mainstream" SVN is - it is related to where it is in the product lifecycle. CVSNT and SVN are both GAINING users, wheras the tools with lots of converters are LOSING users. 2. Your technical argument about "vendor lock in" is invalid for CVSNT (though it is true for EVSCM). In fact I personally see it as the 'opposite' - CVSNT is an open system using open standards and therefore you are must more likely to be able to move your repository elsewhere as time goes on - more likely than using something like (just a random example) VSTS for instance. CVSNT creates RCS files which follow the RCS spec. Any converter which converts from RCS to xyz will work with CVSNT RCS files. The RCS spec allows us to create tags in the RCS files which were not around at the time the spec was written (as any good open spec allows) - but there are a handful of poorly written RCS readers that 'fail' as soon as they see information they are not expecting (whereas the spec says they should ignore any tags they cannot process). The fact that you will LOSE information when converting from CVSNT to ABC is because ABC does not have the same features that CVSNT does and you are losing functionality - if you need those functions or your business relies on that data then the tool you are attempting to migrate to is the wrong one. If you are using Binary Diffs then most RCS readers will fail since they only support a single delta algorithm, however the majority of users I've talked to who use -kB use it to store compiled objects that can be regenerated if sometime as major as a repo migration is going on. With EVSCM there certainly is a greater degree of vendor lock in, though the fact that the data is stored in an SQL database of your choice (eg: SQL Server) ensures that it is readable using many many tools (not the same as an open format though). Finally as I wrote earlier to Bill, There was a great article on the valuation of IT assets published in The Financial Times UK Edition 36,501 on Monday October 1 2007 that talked about the cost of migrating from one system to another. The costs are huge and rarely analysed. When you choose any business system you should be expecting to stay with that for 10-20 years, so you need to be assured it has the features you require and the vendor is going to still be there to support you down the road. Open Source Systems are generally much better for this than 'closed source commercial' systems - just in the years I've been specialising in SCM I've seen many of these come and go and the companies which adopted them have nowhere to turn - they can't even maintain it themselves. Ensuring that the business systems you are choosing use open standards for storage is wise, however that hasn't stopped organisations choosing to base key systems on MS Exchange, MS Office, Lotus Notes, Oracle Financials, SAP or many other 'non-open' business systems - the portability and openness of a system is rarely the key success criteria. Regards, Arthur Barrett