Why switch?

Future? - tla author Tom Lord seems to have stopped developping tla and is currently freshly implementing revc (kind of arch 2.0). Some other people formerly working on tla seem to work on bazaar, bazaar-ng or other VCSes now. tla is not unmaintained, someone was found who takes care of it.
Speed - tla is a bit slow sometimes. This is no big problem and I really don't care if something better is a bit slower than something worse.
Usage - tla usage is sometimes a bit complicated.
Web UI - archzoom can only be made usable by using a revlib, and such a revlib consumes some GB hdd space. Even with a revlib, it sometimes leaves some "dirt" behind when working. The usual way to fix this seems to be a cron script regularly cleaning up. I find this a bit awkward.
arch and archzoom seem to fall over branches with restricted access.
Multi-Platform - running tla on win32 seems to have some troubles. I don't know details, but maybe Alexander can tell more here.
- Mainly, tla was designed around posix file system semantics, relying heavily on file system features like its extensive usage of subdirectories. Especially this point leads to paths that are longer than 256 characters which makes it unusable on Windows (without SFU). Note that there have been attempts to shorten path names in forks of tla.
Age - there seem to be other, even better, simpler and faster VCSes out there now, see next section.

Alternative(s)

Mercurial (hg)

Mercurial seems to be a new, small, fast, nice and easy VCS implemented in Python (and a small C lib for speed when doing diffs). It is used by Xen and some other projects and has been seen to scale up to linux kernel repository size.

There is a converter that can convert e.g. moin--main--2.0 to a Mercurial repository (branch relations not included).

Installation and usage on Linux seems to be very easy and it even includes some cgi / builtin web server for offering web access. It also works on win32 and Mac OS X, please test this to make sure.

Links

Like git, this was developed this year to replace BitKeeper. Its interoperability and migration capability with git is excellent. Written in Python. Seems to me to be a competive, even better alternative to git.

Looking at the mailing lists and the official repositories, the community behind Mercurial seems smaller and less active than the one behind Git, which is nearing its 1.0 release. However, Mercurial is more user-friendly, even compared to Cogito, an user-friendly front-end to Git. For a project the size of MoinMoin, both should work well. -- AdrienBeau

bazaar-ng (bzr)

Don't confuse this with bazaar (baz), baz is just a more useable tla-clone, but the future seems to be bzr. bzr is inspired by baz and others and is written in Python. It is supported by ubuntu and mark shuttleworth.

codeville (cdv)

codeville is a very modern VCS implemented in Python which probably sets the current standars in conflict resolution. is developed by the cohen brothers (bram is well known for bittorrent), but seems to lack the momentum that hg (and maybe also bzr) have. It has more features than hg currently, but mailing list seems rather dead recently.

git

I am very keen on this new system developed by Linus Torvalds this year. It is very capable and should be excellent in conflict resolution situation and merging. Furthermore, it might be useful in situations where a wiki web is copied into two different places, evolved separately and then merged back and made consistent. I do not have personal experience.

Linus Torvalds explained according to Kerneltrap, "in many ways you can just see git as a filesystem - it's content- addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a _filesystem_ person (hey, kernels is what I do), and I actually have absolutely _zero_ interest in creating a traditional SCM system."
- I.e. it is not designed for our purposes and needs workarounds, called wrappers.
  - Wrong conclusion, unless your purpose is really to use a traditional SCM system, that is in Linus' view: CVS, Subversion or worse. (Why this page, then?) Besides, wrappers are not workarounds. Git is made of plenty of simple programs that do one task and do it well. Wrappers tie these simple programs together to provide the common operations expected from a VCS (add, commit, diff, fetch, branch, etc.). Git ships with such wrappers, other people are free to do their own (e.g. Cogito). Note that Git has a tradition of self-disparagement, partly because it's one of the facets of Linus' humor, partly to avoid being a target to BitKeeper's crazy and moving license requirements. Don't let that fool you! -- AdrienBeau
    - I have heard of this work contract/licensing issue. But even then, the heterogenous world of git wrappers doesn't make it better in any case - they just show how flexible the base is. This leads to higher creativity but lower concentration of effort unfortunately.
My team has been switched from arch to git like 3 month ago. Very happy. We currently use git to develop an open source project which contains nearly 13000 files in the stable branch. We sync the git repo with sf.net CVS repo (includes commits back to 2001) everyday and converted all our arch local branches into it. It now contains about 50 branches and is very fast and stable. My experience with arch and git is first of all, FAST. It usually took me about 3 minutes to do a tla change. With git it just pops up with pager and colorizing right after you enter the command. Git also provides extremely good support for patching and merging. It can compare your local changes with upstream(or some other branches) and generates a series of commits that is different with the other in mbox format. you can pipe it directly to mail to send them to a mailing list and if the upstream developers are happy, they can pipe the raw email message to git and git will patch your changes (even with your name as the author). There are too much to say about it, just try it. Also to mention that the git-archimport tool is written by my team leader. If you get problems in importing I assure he will be very happy to fix them.-- PatrickLi 2006-02-22 07:56:21

In the four months since this page was started, Git has kept improving. Version 1.0, 1.1, and 1.2 have been released, new functionnality has been added as the need surfaced, speed and efficiency have been improved even further. The documentation, which was already quite extensive, now includes a good tutorial and a good "cheat sheet" which make Git friendlier to beginners. Several important projects are in the process of moving to Git, including Wine, freedesktop.org's X server, and the Cairo library. As far as I know, the Cygwin port works well, and the Cygwin developers have demonstrated their willingness to work on some performance issues that Git has unearthed. The top two items that I find missing from Git are a native Windows port and the GUIs one has come to expect from VCSs these days (an Eclipse plugin and Tortoise-like file browser integration). Still, I'm amazed by the maturity Git has attained, less than a year after its inception. -- AdrienBeau

By the way, lots of insights in this message from the lead Cairo developer about why he prefers to move from CVS to Git rather than Mercurial (interesting answers, too!) : http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
- He is wrong in his main points about Mercurial though:
  - Mercurial does support branches and tags inside one repository without cloning it (always did)
  - development started at the same time as Git

BTW Git is rather hungry for disk space

Please tell us more about that, with measures, comparisons and/or links to such.

There are some articles from mid to end 2005 dealing with git and mercurial comparisons. They say that git is not storing deltas (or compressed delta) , but compressed hashed contents (revisions) - which consumes more disk space.

Mercurial is not perfect either, it still doesn't have full support for renames, for example...

Those articles are outdated. -- AdrienBeau

monotone

State of the art system currently used for many projects.

<njs> said:
I guess I should be a good advocate and at least say something about why monotone is not written in python :-)

That was actually one of the first questions I asked graydon when I first found monotone, and he actually had a better answer than I've ever heard before the answer was "because it's the only pragmatic language with a powerful type system, and I like powerful type systems because they let me declare lots of infinitely large classes of bugs impossible to express" and monotone's code is really written to make this philosophy true, it's not at all like most C++ I've seen, very nice to hack on, lots of attention paid to things like leveraging the type system and none to things like being the-most-OO-code-ev4r

I'm still a python-head, but VCSes have, like, the single highest robustness requirements of _any_ software you are likely to run into.  Less than, say, medical devices, but more than, say, for example... filesystems.

So it helps me a lot to sleep at night, to know that the compiler will flat-out reject code that tries to gunzip the same data twice, or check out to the path "../../../../../../../home/njs/.ssh/authorized_keys"

Also uses a moin wiki ;-): http://venge.net/monotone/wiki/

darcs

Not an option, we don't want to depend on Haskell stuff if we can have Python stuff. I also guess that being implemented in Haskell lowers amount of contribution and maybe also longterm speed of development.

Actually, being implemented in Haskell has worked out well for Darcs, because the whole Haskell community has jumped on it as their big chance for a killer app. That's balanced out any loss of contribution of speed of development from other folks deciding not to work on it... (they also say, and I have no reason to doubt, that lots of people with no prior haskell experience still find it easy to get into the code and start providing patches). -- NathanielSmith Also, keep in mind that binary packages are available for most platforms so you don't necessarly have to play with Haskell. The Darcs wiki is also moin. And it has nice web interface too (darcsweb) Darcs is great for small projects. but as the project grows with more patches , more files - darcs can become slower. Darcs has great feature of "cherry picking" choose just the patches you want - apply them, remove them and it should work. The main problem is - performance.

subversion, cvs*

Not an option, we just got rid of that CVS-like stuff 2y ago.

comments

Tailor is a tool to migrate changesets between ArX, Bazaar, Bazaar-NG, CVS, Codeville, Darcs, Git, Mercurial, Monotone, Subversion and Tla repositories.
- It looks like Tailor doesn't do branches however.

Developer query

Maybe state your current preference about how we continue:

ThomasWaldmann would like to switch away from tla soon (see reasons above). Mercurial (hg) and bazaar-ng (bzr) look interesting. I already played with hg and it feels good and easy. I also tested and improved an arch-to-hg converter and ran it on the moin branches. As both are written in Python, they should easily run on every system, even Win32.
AlexanderSchremmer really dislikes arch because it's paradigm seems to b0rked. Mercurial is somewhat new and fresh but seems to have a good test suite and a vivid community. I would switch to hg when it has got some basic features like renames (which are used already by our development style). Before that, it would be a too big regression. (Even cvsnt gets renames right, so it's not an uncommon feature.)
VolkerKleinfeld I am more a user then developer, but follow the moinmoin development. Just to confirm that mercurial works quite nice for windows machines. Would be nice to have moinmoin available from mercurial!
Bazaar is nice, support the current development style, and will make it very easy for people to contribute. See the 5 minutes tutorial. I'm using it now for few small projects. It is still buggy with Unicode file names, but thats not an issue for moin. It will be a good idea to import moin code into bzr and try the common operations on various platforms. -- NirSoffer 2006-02-06 18:03:10
... (add your state of mind here) ...
- ... insane ...
Why is Subversion a "no go", too? I agree about CVS (there is next to no reason to stick to CVS), but SubVersion works excellent, is widely used, and SVK is a great distributed "add-on" for it. So people can make their own local branches, commit locally and so on, at no additional costs.
- Besides some VCS features: SVN is too big for my taste. and that it has some core functionality not built-in, but even needs more SW (svk) for that, doesn't make that situation better. Also, it is not in Python (and I like to be able to hack the stuff in my preferred language, if needed). SVN is definitely better than CVS, but we already have something better than CVS now (GNU arch), so that would be no reason to switch. I like the name, though. -- ThomasWaldmann 2006-03-15 17:16:52

MoinMoin: NewVCS