Why just one DVCS?

There are a lots of flame wars out there about the best DVCS (Distributed version control system), like others (IMHO) ego wars (KDE vs GNOME, VIM vs EMACS, etc). There are very good options like git, mercurial, bazaar or darcs and many people (as GNOME is doing right now with all the survey thing).

Even in my company, we were (actually, we’re already) discussing about the right one for our day by day at work. We’re almost sure to adopt a good dvcs is better than our well known Subversion, but we don’t know the best option.

We could follow the typical technical reasons people usually does, but we must also pay attention to other (more practical) reason. For example, we develop linux distributions (mostly) based on Ubuntu, so that tell us we should use bazaar to make easy clones, branches, merges and any kind of tasks in order to collaborate.

But, in other hand, we work with rails. Rails and projects around use git intensively, so makes sense to use git as well.

And we also work with other projects which still use subversion or even others systems.

After think about the best possibility it’s clear for me that choose just one makes no sense at all. We can choose one for working internally, but we’ll still have to deal with with other system we work or collaborate with.

Our major project is the technical level and background of the people here is very heterogeneous. We got very geek guys and people who just got out from the university and don’t know to much about real life tools…

So, we need something with learning curve small enough to normal people could just use the dvcs and good enough to use in professional projects.

But I really think the best way, at last, is to learn the basics of each one (of the most common ones), use internally just a good one, but bring to the people the way to use whatever they want or need for each project. I think John is right about that… why to choose for the people? Let’s people decide by themselves.

I was talking with Alberto about this and we agree (didn’t we? :-P) that to have a kind of interface which makes abstraction about which dvcs is below and gives us compatibility between them, probably is better than try to push people to one or another system just because we think is the best.

There ar to much big (and little ones) projects which have already chosen git, bazaar, mercurial or other and are very happy with their decision to just change because someone say so…

I don’t think to expect that is very realistic…

I know this is possible and we as open source and free software people doing all the time: make open standards, communication APIs, and abstractions layers. I don’t see more complex than a lot of projects (GNOME itself) does al the time.

I think I will sum myself to the John’s count he is meaning to do something similar 🙂

Mercurial 1.1 is out

2 day ago was released the last version of Mercurial (HG). The changes look great 🙂

Some changes:


  • Added ‘resolve’ command for better tracking of in-progress merges
  • Several speedups for status and diff commands (especially on Windows)
  • Some modules have been rewritten in C for greater speed
  • Compatibility with Python 2.6 2
  • Add some buffering to the templater
  • Better documentation on git diffs

    Web interface:

    • Add a canvas-based repository graph
    • New and improved hgweb themes: paper, coal and monoblue
    • paper is now the new default style; the old default is now called ‘spartan’
    • Better WSGI compliance
    • Collections now show nested repos (best used without a checkout)
    • diffs are more sensible, follow diff.git settings
    • Better alternative for repository collections


      • resolve: new command to help keep track of merges
      • merge: only implicitly select same-branch heads
      • export: append instead of overwrite when exporting multiple changesets
      • bundle: added support for different compression types
      • rollback: clean up empty files
      • tag: without a checkout, use tip as the tagging revision’s parent
      • log: allow searching by user (with -u)


        • rebase: new extension to support rebasing changesets
        • bookmarks: new extension to provide (local-only) git-like branches
        • zeroconf: new extension to support publishing repositories through Zeroconf/Bonjour
        • convert: added support for conversion from bzr repositories
        • color:
          • add colorization of diffs
          • add –color options to many commands
        • bugzilla: added support for Bugzilla 3.0

        See the full Release Notes for more info.

        BTW, we’ve just created a public personal (and for groups and free software projects) mercurial repositories at Emergya (at last!) 🙂

        Here mine with some silly repos:


        Enjoy! 😉

        Creative Commons Attribution-ShareAlike 3.0 España
        This work by Juanje Ojeda is licensed under a Creative Commons Attribution-ShareAlike 3.0 España.