There were some suggestions in respose to my last bazaar-ng post to look at other systems. I was aware of each DVCS (distributed version control system), but haven't used them. How am I possibly supposed to make a decision?
Arch is dead. Whew, that was easy. Bazaar seems to be the successor, and Bazaar-NG is the successor to Bazaar. Wait, dammit, it's not dead. But I'll just ignore it since the UI has always seemed confusing and weird.
Darcs seems to be the not-disfunctionally-managed peer to Arch; I think Arch is older, but Darcs is older than everyone else. Notable for its novel implementation language (Haskell). People complain about its speed and memory use. Otherwise, it seems very capable, and fairly straight-forward. It uses email very heavily for communication, which is a turn-off for me, but not unjustifiable.
There seems to be some debate about its merge algorithm. As a Subversion user all of these are going to have far improved merging, so the distinctions don't mean much to me. Any of them will seem like a breath of fresh air. This reminds me of the DVCS vs. VCS debate when Subversion was being developed; the DVCS people missed the point that CVS users didn't even know what they were talking about, and Subversion provided the improvements that people actually wanted.
Git, Linus Torvald's entry. I hear it is confusing. It's not really a DVCS, just one piece you might use to build a DVCS. Cogito seems to be the leading frontend to Git. The whole thing seems silly... I kind of understand where they are coming from, but it's a side project for everyone involved, and the usability issues seem like such an afterthought. As a project it doesn't make sense to me. A similar idea might be the extraction of Subversions filesystem layer as an equivalent to Git (which is exactly what svk does).
So, SVK takes a piece of Subversion and adds DVCS on top of it. This means that it is easier to work with Subversion projects without forcing the upstream project to change their system. I'm not sure about how smooth the process is -- svk adds special properties to manage the merging process, and I assume other tools ignore those properties, and so the merging is improved from Subversion, but only when you are using svk alone (at least, that's what I'd guess). I hear iffy things about its usability. It is implemented in Perl; many implementation languages are good candidates, but I must admit I have a bias against Perl as it encourages sloppy programming and poor error handling. But that may be unfair -- good error handling (which is essential for any VCS system) isn't really automatic anyway.
SVK has some significant strategic advantages over the other options. At least from my perspective Subversion has successfully supplanted CVS everywhere I go. SVK seems to be taking a page from their book.
Mercurial is a version control system that popped up around the same time as Git, after the Linux/BitKeeper relationship went up in flames. Its most notable feature seems to be its speed. It also has one of the easiest commands to type, hg (the chemical symbol for mercury). It has some simple client/server support (that's not purely hacked on top of scp or other tools, which I personally dislike in many other projects). It is written in Python. I don't know more about it.
Bazaar-NG I talked about earlier. It is also written in Python. It has a lineage from Arch (which itself has been written in several languages), starting with UI enhancements and then a more signficant rewrite. It is sponsored by Canonical (also known for Ubuntu), which makes it seem unlikely that it will simply fade away; this seems pretty significant to me, considering the number of current options. I find the client/server parts underdeveloped, though it does seem to be a specific area of current development. They seem interested in a pluggable architecture as well.
Monotone is another system. My eyes are blurring at this point. It is written in C (or C++?), which has become rather unusual. It uses SQLite underneath. I have no idea what its advantages are. Despite the implementation language I don't get the impression that it is faster than the other systems. Strategically the implementation language makes it a difficult project to develop.
I guess that's all the major players now? Did I miss someone?
There's a number that seem to have fallen by the wayside. Codeville, for instance, is just a side project, with its most notable feature being merges. Who knows about the other Arch forks. The Monotone site has a list which seems a little old, but because of that shows there's a lot of turnover. Less turnover now than a year or two ago, but still a lot. This is why viability seems like a major issue in selection.
Personally I'm not terribly interested in comparisons put into tables of yes/no on different features. Things that seem important to me:
Git or Cogito are not that terrible to use, and, in fact, they're quite pleasant to use. Their shortcoming is that they're not very portable (at least to win32 native) or there's little effort in having an usable win32 binary. Mercurial has proven very powerful and it's really concise and easy to use. The Xen people are using it and I do it myself with home grown pet projects... without any hassle. I would tell you, give it a try!
Sorry to nitpick, but
"Bazaar seems to be the predecessor, and Bazaar-NG is the predecessor to Bazaar."
"Bazaar seems to be the successor, and Bazaar-NG is the successor to Bazaar."# Will
Yes, that actually makes sense then ;) Corrected
Just to correct one minor misconception -- I have yet to use e-mail with darcs. (Other people have sent me a patch or two, but I've never used the send feature myself.) I always use ssh/scp. E-mail integration with darcs is a feature, but not one that's necessary to use.
I haven't had a chance to use bzr-ng seriously yet, although one Python OSS project I'm involved with is switching to it soon-ish. My current belief -- which is probably obvious ;) -- is that darcs is quite nice for small projects, while svn is best for large projects. bzr-ng presumably is fine for both, but I think it has some sharp corners still.
The reason the darcs merging algorithm is talked about is because the algorithm has a huge impact on how the program works. The big problem is that if you try to merge two substantially similar patches, you'll get a conflict which kicks off a comparison against every line of every patch you've ever put into the system. Needless to say, this causes the app to hang (sometimes for hours) and is thus a subject for debate. You rarely run into this, but when you do it's annoying to have to do the dance to get your repo in working order again.
darcs is my favorite vcs because it's terrifically simple and by default has interactive prompting for patches and you can push or pull between repos. The email stuff is just another transport, normal transport is via scp (transparent when using push/pull). I wish it didn't have the merge problem so I could recommend it to people.
The only two dvcs systems I'd look at today are svk and bzr.
Bah, re-read the darcs conflict bug when I posted and realized I didn't describe the conflict correctly.
The conflict compares every line of every patch to every line of every other patch that you've ever committed to the system. It's very ugly when it hits.
I've been using mercurial a lot lately, and it really is a delight. It's nicely self-contained, so its easy to set up on a new machine. It works quickly, and keeps working quickly as the project grows. Because it was written to be able to deal with the Linux kernel from the outset, the ability to scale with project size is a basic design requirement.
It works well in practice; the command structure is easy to pick up if you have a cvs/svn background. It supports 3 modes of remote operation: a CGI script which can be used for either manual browsing of the repo, or for mercurial push/pulls; transport over ssh with no requirements beyond mercurial being installed on both ends; and bundles which can be emailed around.
Mercurial is also being actively developed, and shows no signs of stagnation. It also has an extensions mechanism which allows extra functionality without cluttering up the core; current and proposed extensions include graphical history browsers, other merge algorithms, and so on. One particularly interesting one is "mq", which allows you to maintain a stack of patches against your tree, which can be pushed and popped in a manner very similar to "quilt"; this is useful for maintaining a set of small local changes against someone else's project, or for doing experimental changes without creating branches.
I've also used monotone, which I was quite keen on for a while. However, it seems pretty slow in practice, and doesn't scale well with project size. It has a lot of interesting ideas in there, but they're not particularly well developed.
Alright, enough fanboy.
I'm liking Mercurial as well.
I think it's easy for people to get the wrong idea since it has some git-compatibility. I find bzr less elegant in comparison, but both are still have some time to go before 1.0.
Well, dunno what you mean by a "side project" wrt. Git and Cogito - it's certainly not a "side project" for me (I maintain Cogito) and AFAIK not for Junio (the Git maintainer) either. Also, it is used extensively for the Linux kernel development, which makes it not likely to fade away either. Otherwise, I've found your comments confusing since it's not clear what exactly is wrong with it other than it "seems silly". We obviously love specific feedback, tho' (even from non-users to explain why they do not like us and what can we improve to fix it).
I guess I got the impression due to Git starting with Linus, for whom it of course is a side project. Sorry that I didn't notice the maintainership had moved around. Also, many Git frontends have come and gone -- while Cogito seems to have emerged as the preferred frontend, it adds to the confusion.
Git itself just seems like an internal implementation detail. An important detail, perhaps, but not very important to a user. So it comes off as strange because Git is kind of the front man. Then starting from the Git page, Cogito links to an index of source files, which comes off as very hackerly and a little half-hearted. Linus's opinion on programmer accessibility (which he seems to be against) perhaps also colors my view on these things.
That said, I haven't used Git or Cogito (I hope I didn't imply such -- I haven't used any of these except very light bzr and darcs use), so this is a shallow summary.
Hmm, well, Cogito was there from the _very_ start (it popped up one or two days after Git 0.01, I think; first under the git-pasky name, but the first month was just very wild). I don't think there was actually any big fluctuation in the Git frontends, I can't remember any Git frontends which came and gone - which ones do you have on mind?
In fact, from Cogito point of view, Git indeed _is_ an (important) implementation detail. Perhaps I didn't put enough accent on Cogito being a version control system on its own.
I'm confused about the Cogito link, the only link I can see leads to the list of release tarballs - is that what you mean, that it would look better if there would be a direct link to the latest version? It wouldn't ever occur to me that this might make a negative impression, but perhaps you are right... - that's a valuable observation (if I understood you right, that is), thanks!
There's several pieces listed on the Git website, and when I've seen Git in conversations I've seen people refer to a couple different pieces. Many of those pieces may not be version control systems... all I know is there's a bunch of things, and it's unclear which is which. That "Git" gets all the fame due to its lineage, yet is a fairly low-level bit of code, probably doesn't help the situation.I'm confused about the Cogito link, the only link I can see leads to the list of release tarballs - is that what you mean, that it would look better if there would be a direct link to the latest version?
No, there should be a link to a real website! That website should show a quick sample of how to use it, links to docs, etc. It would probably be good to explain Cogito's relation to Git and other tools as well. A link to an index of files gives the impression that it's a really low-level tool, or else that it is a tool very early in its development. At least that's what I usually think when I encounter such a page.
I've never really understood what Linus is talking about when he says "git is not a DVCS" -- it tackles all the same problems every other DVCS does. AFAICT the only thing it means is that the UI is sometimes lower level than a user might want. I'd suggest mostly just ignoring the "not a VCS" thing entirely. People use it as one.
Isn't Git more like a versioned filesystem? That's what Subversion and SVK are built on, but Subversion and SVK aren't the same as the versioned filesystem underlying them.
This is an evolution problem, and the situation _is_ somewhat confusing. At the beginning, there was a tool called "Git" which provided very lowlevel commands in the "versioned filesystem" spirit, and on top of that was founded Cogito which provides a real DVCS interface (and I believe it has in fact one of the best UIs out there; but don't believe me, I wrote the thing ;).
So at the beginning, the "this is not a DVCS" notion was true. But that only held for the first several months. Then, various scripts appeared even in Git that started providing a real DVCS interface ("porcelain") you are used too (although the Git UI may be perceived as clumsy), so by now Git is a DVCS on its own, _at the same time? as it still provides the lowlevel interface ("plumbing") e.g. Cogito uses.
Don't get me wrong, but the problem with cogito/git is that there is no webpage claiming: "This is git, that is cogito. You can use it using this 10 minutes to success tutorial..."
If i google up "git" or "cogito" i don't get any results. Only a combination with linux or kernel returns me a link pointing to kernel.org/git. And there is nothing related to git :-/
git.or.cz is the fourth result when googling git, cogito directory on kernel.org is the fourth result when googling cogito and cogito's README is the fifth result. But I agree that Cogito needs own homepage and the Git's homepage is too brief, I've bumped its priority and will try to expand it. Thanks for your feedback!
Ah. Setting google language settings to English improved the situation. My prefered language was German and there were no results :-(
I dunno what the decision procedure for determining what a "VCS" versus "versioned filesystem" is. Certainly git has nothing in common with every other thing called a "distributed filesystem" (e.g., NFS, cluster filesystems, etc.), and everything in common with VCSes. Even from the very beginning, it was never possible to write _interestingly different? VCSes on top of git, because it defined all the semantics of what would be stored, and what wouldn't. You could put different UIs on top, maybe use different programs to actually copy the data around, but that's true of every VCS...
Not really an important argument, but I think there's enough noise in this space without continuing to perpetuate this bit :-)
I have been using Bazaar-NG for about 6 months or so, during which I have been trying to keep up with their mailing list discussions. Before Bazaar-NG I used Subversion and Monotone. I like the idea of "Distributed VCS", and so far Bazaar-NG seemed like the best one at that for me. That is, Bazaar-NG is still a work in progress, and they do some great stuff there, with great ideas. I'm a fan of Martin Pool and Aaron Bentley, two of the drivers of Bazaar-NG. Martin Pool is a great VCS designer with great patience, it seems. He is the leader and maintains the main repository. Aaron Bentley has many great ideas that he adds in his plugins project (BzrTools). One of the cool things that I used in BzrTools was the push/pull or something like that. But then there is this PQM thing which should be a patch manager, which I generally don't really care about, but they need it. Thus, Bazaar-NG moves sometimes more slowly towards the designs than I wish, and some of its design ideas like PQM don't really relate with me.
The first time I read about Mercury it didn't seem quite ready as well. But now I feel like giving Mercury a try. If it proves to make client/server with "distributed" well enough, while supporting Windows with confidency, I might switch to it for another 6 months, giving time to Bazaar-NG to mature beyond the initial design goals. Also, maybe this relation of Mercury with Git may be attracting many people to Mercury, because their mailing list seems to be quite active as of late.
Thanks? :-)# Joao
I'd recommend looking at Mercurial too. Simple to learn, and has a nice bunch of people on the (very active) mailing lists.# Dan Lewis
After an extensive experience with CVS at work, for my personal (i.e. no serious need for distributed VCS) projects that are now more or less in CVSNT I'm considering Mercurial. On paper, it seems to have good features, good performance and unusually good Windows support, not "someone wasted his time to compile an unofficial binary of an obsolete version that we don't want to contaminate our server with" or "using Cygwin it more or less works for most people", as seems more common. Am I going to miss something the other wonderful systems have or to find limitations?
Mercurial is behind bzr, darcs and others with respect to some simple features, and some things do not work as well in Windows as bzr or darcs.
In particular, Mercurial has quite a few problems with renaming, which are a mostly recent addition. It also has the strange notion that you cannot add directories, because it doesn't "do" directories. You can add files in a directory though.
Mercurial's greatest benefits over bzr and darcs at the moment seem to be the short command, "hg", and the multi-head support, which some people admit they don't use simply to avoid confusion and human error. You can approximate multi-head functionality with lightweight branches.
Mercurial doesn't have as much developer support and needs help.
Mercurial also suffers from some slight UI issues not affecting either bzr or darcs. Sometimes it seems the Mercurial folks are against dealing with some of these issues, because it goes against their principles, but it seems very simple to me what to do on rename, and it was apparently as simple to the developers of bzr, darcs, monotone and more.
Mercurial Windows support is primarily an illusion. The bzr site is a mess. Following the Mercurial tutorial using bzr is easier than doing so using hg. Give it a try, especially if you use Windows.
How am I going to decide between Bazaar-NG and Mercurial now? :-)
I installed Mercurial and am using it. But I reckon that Bazaar-NG does somethings more user-friendly like you mentioned.
Now I don't know anymore... Maybe I'm going back to Bazaar-NG with a 0.8 pre-release...
I decided to keep using Mercurial for now.
I'm afraid my sarcastic description of window versions applies to Bazaar-NG.
http://bazaar-vcs.org/BzrOnPureWindows says: Failing tests in bzr 0.6 selftest is failed for some tests. Mostly because some tests written in non-windows compatible way.
The current version is 0.7: failing tests can be a temporary problem, but not updating the results clearly shows neglect. Now I've found the Windows installer, but the first choice seems to be Cygwin. Can you explain the shortcomings of Mercurial, apart from developer attitude and lack of renaming support, and the specific Windows problems it has? You make very generic statements.
If I wrote up a document on this and all other evaluations I perform I'd have no time for work and I might unwittingly cloud the issue in the future by providing a checklist of problems for poorly reviewed VCS to quickly gloss over. So, evaluate them yourself.
Do the hg tutorial with bzr and hg, skipping the export section. You can add darcs and monotone to your short-list if you want.
Then do some of your own evaluations, like a simple rename, dir rename, merging divergent branches where one contains a renamed file which the other branch made changes to under original name.
Finally, evaluate a simple de-commit of changes.
Keep and eye on "log" (bzr/hg) and "changes" (darcs) when evaluating.
This takes less than an hour for each. You should find the results telling.
You should find bzr ui and functionality superior, but if you don't there's no need in anyone changing your mind, use what you like. In the end, I like mercurial for almost indescribable reasons, it has a better name and a more admirable history, but I can find solid technical reasons not to use it. I can find less (or no) technical reasons not to use bzr. I do believe it makes sense bzr is functionality and ui superior.
I evaluated hg, bzr and darcs fully, but discarded monotone early because I didn't like the ui. bzr, hg and darcs are all great and at a different time in their lives as products I might be inclined to pick any of them. But, I need VCS right now, and right now it seems bzr is the best choice.
You do not need any cygwin stuff for hg, bzr or darcs. If you find anything related to cygwin, skip it and look elsewhere. The bzr homepage is admittedly confusing, especially when it comes to downloads, some pages need to be deleted.
P.S. I just learned bzr shared repos are like mercurial's multi-heads (and perhaps less prone to human error).
It looks like mercurial's Windows support is even worse if you use the official source distribution. Some of that obviously makes its way through even in the Windows-friendly package from Bryan O'Sullivan.
I noticed this as I am now evaluating the ease/difficulty of contributing to each project (I even get to fix the same thing in both bzr and hg).
However, I will need to fix even basic things like "hg diff" in Windows if I want to contribute other Windows fixes. I didn't have to do anything like this using bzr, because the core distribution already works in Windows.
Do you want VCS, or DVCS? If you don't need distribution, or can live with a centralized repository with a lightweight network protocal and the ability to work detached, the there's a clear winner that nobody has mentioned yet: Perforce. Yeah, it's commercial. But they'll give free licenses to open source projects. They support more platforms than most OSS projects. Lots of add-on and extras. Lots of flexibility. It doesn't leave turds in your workspace. A command name (p4) that's as short as mercurials.
And the kicker - it's the only VCS I've ever encountered that gives me the kind of control I really want over a merge. After doing merges with perforce, every other VCS feels like I'm throwing my code against the wall, and hoping the right parts stick.
You can make "p4 resolve" act like other VCS merge commands, and merge everything it can and let you deal with conflicts. Or you can get an interactive loop, where you get told about the potential merge, can examine the files, or the automated merge, and choose to use anyone one of those three, or edit any one of those three and use that.
I can - and regularly want to - do things with perforce's merge that are at best very painfull, and in some cases impossible, with other VCS systems. If a VCS can't do the equivalent of "p4 resovle -at", it isn't going to replace perforce for me.
In reply to kai:
You didn't give any details on problems you had with Mercurial. Can you post some specifics?
I'm using Mercurial 0.9.3 on windows and linux quite successfully. Rename works just fine for me. Developer support has been great. (For example, look at the very helpful and patient posts in the Mercurial email lists.) What UI issues? Your last paragraph appears to be confusing Bazaar with Mercurial, so I don't understand what you were trying to express.# branch
Well, since Nathaniel isn't going to advocate Monotone, barking up his own tree, perhaps I'll do it! Monotone is solid, especially for a system that is evolving so quickly. There are a lot of great work being done there. It has one of the most thorough test suites I've ever seen for regression testing; bugs that get fixed don't get a chance to resurface. The upcoming release of 0.26 will bring in some important changes to the software, making it more robust, quicker, and more useful. Honestly, I cannot see working with any other tool, now that I've worked with Monotone. Here's the recent pre-release notes for 0.26pre3: http://www.venge.net/monotone/NEWS.pre.
I've recently been looking at mercurial, bzr-ng, and svn/svk.
As far as I can tell, bzr-ng doesn't support tags. I'm not 100% sure of this, because despite claims to the contrary, the website is a mess - do checkouts/repos work in the released version, or not? What is the released version? There are 4 different tutorials, but no reference manual.The "bzr for SVN" entry is just an advertisement about how much better the merging is. All of this is too bad, because I want to like it - it seems like it has the best shot of becoming the de-facto standard, long supported VCS.
I like the feel of mercurial, and for stand alone projects, I think I'll be using this. It also seems like a good choice for versioning arbitrary directories (e.g. /etc/postfix).
But there seems to be a fatal (from my point of view, for my particular application) flaw for all of the DVCSs: they don't handle integrating third-party libs etc. as part of a bigger project. You can't "bring-in" a particular subset of one repo into a different location in another. Yeah, there are ways to work around this with scripts that do recursive checkouts or whatever, but then I don't get the benefits of consistent branching and tagging, and the system ends up being less cabapable that CVS (in this particular area, but it's an important one for me.)
So I'll probably end up migrating to SVN, and hope they are able to get their act together w.r.t. merging soon.
But there seems to be a fatal (from my point of view, for my particular application) flaw for all of the DVCSs: they don't handle integrating third-party libs etc. as part of a bigger project. You can't "bring-in" a particular subset of one repo into a different location in another.
The core Bzr folks have been using the config-manager tool from Robert Collins for doing just this from back in the Arch days before Bzr existed. config-manager also allows one similar functionality to tags. If you want more tightly integrated functionality, bzr is pluggable (so having bzr subcommands call out to config-manager should be quite simple to implement, and not require any changes to core bzr code).
Personally, I'm waiting for Bzr's cherrypicking support to catch up with Arch -- when I've asked the core team, they indicated that such was a pre-1.0 feature. While they've kept backwards compatibility (via support to upgrade repository formats), bzr's backend is still very much in flux.# Charles Duffy
That is exactly my thought. How do you deal with library source code shared between projects? I would like to use a Dvcs, but this factor and lack of a gui interface are things that hold me back.
Despite Linus's comments on: http://www.youtube.com/watch?v=4XpnKHJAok8
I actually find CVSNT to be ok for now, and it does handle repeated merges ok (maybe not for a kernel sized project though).
Charles# Charles Pope
Six months ago, I was doing the same research and asking the same questions. I ended up going with bzr, mostly because I like the UI. Also, from lurking on the mailing list and seeing a core group of active developers with a common vision, the support of Ubuntu, and a lot of attention paid to UI/usability issues, and just generally doing the right thing, I feel confident that it will mature nicely. Plus I need both Linux and Windows support, and being written in Python I'm willing to believe that portability will be taken seriously even if right now it isn't quite. I don't think it is really ready for prime time yet, but it is self-hosting, and as a solo developer I've been satisfied with it.
The web site is weak, but interestingly enough this web page has gotten the attention of the key contributors, so perhaps that will improve soon. :-) The tutorials are a good enough start though, and the built-in help has been sufficient.