[cvsnt] How to convince developers

Arthur Barrett arthur.barrett at march-hare.com
Fri May 23 22:45:51 BST 2008


> 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

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

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.


Arthur Barrett

More information about the cvsnt mailing list