Source management
Contents |
Criteria
- distributed/centralised
- performance
- stability (has been used since long, by lot of projects?)
- conversion tools available
- works in both linux/windows
- well integrated in linux/windows (graphical interface, integration with file browser)
Some comparisons
distributed
mercurial
Very simple to use. (used by orzel, we are big fans of mercurial here at freehackers). References : Xen, Xine, open solaris, audacious, mozilla and others
User/permission management used to be difficult (that's more complicated to achieve with a distributed system) but now there is http://www.lshift.net/mercurial-server.html
linux support
No great graphical interface for linux. You can use "hg view", if configured properly in ~/.hgrc (my conf as example).
[extensions] hgk=/usr/lib64/python2.5/site-packages/hgext/hgk.py [hgk] path=/usr/share/doc/mercurial-0.9.5/contrib/hgk
Despite being tcl/tk, it still definitely looks polished and great. You can browse but no do any action (up, pull, push, merge..)
I still can't understand why you need to put full path in some .hgrc and use the "hg view" call, instead of having a great command in path, with no configuration, as usual...
windows support
This is a real pain to install on windows, especially if you want ssh support. There are binaries though :http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages
explorer integration looks promising, but is even harder to install (you can't use windows binaries, dependencies requirements even uglier..). I have managed to install it, but it doesn't do anything.
bazaar-ng (bzr)
- Simple to use (used by panard) - need no configuration step
- Really reliable (I use it intensively, and I never got a bad behavior...) : no problem with binary data, deletion and moves are well handled, etc.. (even after hundred of merges from hundred branches) (I got a lot of problem with mercurial with the deletion)
- Performances are quite good
- Auto setup of push locations (really usefull for mirroring archives)
- Possibility to share patches between branches in a top-level directory (save a lot of space disk!)
- Lot of (usefull) plugins http://bazaar-vcs.org/BzrPlugins
- Some graphical interfaces (even qt - QBzr, look at plugins)
- Python written, plugins are easy to write
- Works on windows (not tested)
Nothing to do with TLA. For my part (panard), the best distributed VCS (scale well with different sizes of project)
darcs
developed in haskell (fonctionnal langage). Seems sexy too.
Very simple to use.
Good doc and interesting patch management theory well explained.
arch
hard to setup, hard to use.
not clear how it relates to some other tools on top of it. (tla,arx,bazaar..). Those are frontend, implementation or forks.
bazaar
Fork from tla/gnu-arch. What a mess with tla/arch/bazaar..
mozilla considered using it. decided for mercurial for speed/perf.
svk
works over svn. buggy, hard to use.
windows?
Git
The one from linus, hard to use, even with cogito.
Very bad support for windows. ("half work with wine")
qgit4 is great, available for both linux and windows. (but still, underlying git is not 100% functionnal under windows)
Monotone
mercurial uses the basic monotone history model. (python)
- use an embedded sql database. Only one network protocol available (netsync)
- use sha1, but for what..?
- everybody says that it scales very badly
monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. it understands history-sensitive merging, lightweight branches, integrated code review and 3rd party testing. it uses cryptographic version naming and client-side RSA certificates. it has good internationalization support, has no external dependencies, runs on linux, solaris, OSX, windows, and other unixes, and is licensed under the GNU GPL.
centralised
CVS
The old and original one. Super-easy to create a new repository. Lot of bad things. Is now obsolate.
Subversion (svn)
The new one. Does the job well. You want to use the fsfs storage backend. A lot more reliable than other backend, and make rsync/backup so efficient (one file/commit)
Others
Clearcase
Come on :-)