One of many free distributed version-control systems [LWN.net]

One of many free distributed version-control systems

Posted Dec 15, 2007 17:58 UTC (Sat) by stevenj (guest, #421)
In reply to: One of many free distributed version-control systems by davidw
Parent article: Canonical releases Version 1.0 of 'Bazaar' version control tool (Linux-Watch)

What happens if you put some effort into one and it fades away? Then you have wasted your time, and now have your version control history in software that's not going anywhere.

Not at all.

First, anyone who has used any DVCS will probably tell you that they are a vast improvement over a classic CVS-style VCS, and will certainly save you time and aggravation. CVS is truly primitive in comparison to any modern VCS. And if you learn one DVCS, the concepts carry over well to pretty much any other DVCS. So, you haven't "wasted your time;" quite the opposite.

Second, you are not locked in; as I said in my original post, there are already several conversion tools that let you transfer your version history between DVCS systems (and import from CVS or Subversion). This is one of the nice things about using free software and open formats, because FLOSS developers practice what they preach when it comes to interoperability.

People who have never used a modern DVCS should be cautious about speaking from ignorance.

(Log in to post comments)

One of many free distributed version-control systems

Posted Dec 15, 2007 19:36 UTC (Sat) by davidw (subscriber, #947) [Link]

I read things like this:

http://blog.moertel.com/articles/2007/12/10/how-i-stopped...

And what it says to me is that I might as well wait until a winner emerges.  svn is "good
enough" for me, like it is for many other people.  With a limited amount of time at my
disposition, "good enough" is a conscious choice to not bother with "better/best" until the
better option has been fairly well nailed down.

The name for this behavior is "satisficing", as opposed to maximizing, and in reality, is
something that we must all do.  We can't all follow the latest and greatest in everything in
our lives - it's simply not possible in terms of time constraints.

For some people, the benefits of a bleeding edge version control system may be worth the
costs, for many others, they're not.  For some people, playing around with the latest version
of Erlang, Haskell, Ocaml or Scala is critical.  For other people, that's not important.  Some
people need to follow the development of the Linux kernel in order to keep on top of
improvements for massive server deployments.  That's not so important for other people.

The point is that it is, like many things, a tradeoff, and that chasing after the latest thing
in this field may quite well be a waste of time for some people, such as myself, for whom
existing systems like svn are adequate, even if we realize that better things are available.

One of many free distributed version-control systems

Posted Dec 15, 2007 21:10 UTC (Sat) by sward (subscriber, #6416) [Link]

Surely, you should continue to use Subversion if it meets your needs.  Version control tools
are not something you want to switch lightly (although the switching costs really aren't that
high).

I would not class bzr, hg, or git (or svk, for that matter) as "bleeding edge" anymore.
They've all been used successfully on real projects.  And the risk of lockin is minimal, given
the conversion tools that already exist for all the major version control systems.

One of many free distributed version-control systems

Posted Dec 17, 2007 8:06 UTC (Mon) by aleXXX (subscriber, #2742) [Link]

> (although the switching costs really aren't that high)

The switching costs can be high.
If you are in a commercial setting with developers on UNIX and Windows 
platforms, then the switching costs can be really high.
Switching the VCS means
-several man days if not weeks for somebody to evaluate the alternatives, 
including finding mature GUI clients for all platforms
-a few man days for the VCS admin to actually do the switch (maybe 
creating the new repo doesn't take long, but it has to be made sure that 
it really works, has everything, permissions are correct, history is 
correct etc.)
-1 day for everybody for a quick introduction to the new system
-some time for each developer to learn the new stuff
-several man days for the VCS admin for helping the newbies

Sum this up and depending on the number of people you can get man months.

And you may have developers who are not that flexible, and don't like to 
change in general. If they are not really pro-open source, switching from 
one open source VCS to another open source VCS will make them think even 
worse about open source: "we have to change all the time, because the 
previous one didn't work."
Having a solution which works for years really gives them a feeling of 
stability and reliability, switching once a year feels like "nothing is 
good enough to rely on".

Alex