Version control systems

I left last night jhbuild compiling all GNOME modules, included meta-gnome-proposed, to find this morning it failed on libtelepathy because of missing darcs in my system. Installed it and watched it work until it came to another module needing bzr, installed again, and then, a few minutes later, another module complained about missing mercurial. And so far, so good, but this makes 6!! (if not more, it’s still compiling :-) ) version control systems needed to compile GNOME unstable, that is: CVS, subversion, git, mercurial, darcs and bzr.

While I have nothing against people writing/using their own tools for whatever they want, it started to look to me, exaggerating, of course, like the Linux distro market, where, if we continue the trend (fortunately, the number of distros is not increasing, like it did a few years ago), we’ll be having almost a distro per Linux user. So, although I don’t know in detail all of these VCSs to really understand why they all exist, is this really needed? Wouldn’t it be better to have 2 or 3 very good VCSs that fit most people’s needs? If not, I’ll write my own :-D

Tags: , , , , , , ,

6 Responses to “Version control systems”

  1. you see, once upon a time, there was a desktop-environment (KDE).. but some people thought that it’s not ideal, so started to work on a different environment… and now we have two :)

    from the 6 you mentioned (CVS, subversion, git, mercurial, darcs and bzr),

    CVS will probably die out (will be replaced by SVN or something better everywhere)

    from the remaining 5, they can be divided into 2 groups:

    1. centralized ones: svn
    2. decentralized (distributed ones) : git, mercurial, darcs, bzr.

    from the decentralized ones, darcs is a fairly strange beast, but the remaining 3 are quite similar in how they approach the version-control-problem, so for an experienced user, switching between them shouldn’t be a big problem.

    but on the other hand, they simply focus on different things (for example, git sacrifices practically everything (user-friendliness, windows-support (I_KNOW_THEY_ARE_WORKING_ON_IMPROVING_IT) etc) for performance), so as always, different people, different needs :)

    but on the positive side, between git/bzr/mercurial converting repositories is not that hard.

  2. ovitters says:

    Suggest not to approve those spam trackbacks.

  3. Most of them are required for proposed modules (gtk-vnc needs mercurial, swfdec needs git, mousetweaks needs bzr, who needs darcs?); I can’t remember if module acceptance requires to be under svn.gnome.org but that is certainly a plus.

  4. Sean says:

    I think you should require svn.gnome.org for module acceptatnce. It is ridiculous for you to have to do all this extra work dealing with everyone’s particular version control preference.

    Sean

  5. Anonymous says:

    We already have one VCS which could work for everyone. Which one is left as an exercise for the flame-retardant reader.

  6. pete says:

    Wouldn’t it be better to just have a uniform way of getting the latest revision from each of these repos? Then jhbuild could just depend on uni-vcs and use it to grab sources from any cvs, cvn, darcs, bzr, hg, git server.

    Preferably this would be implemented server side, but I suppose you could have a simple program that supports checkout for each…