This post is very old. Please bear in mind that information here might be incorrect or obsolete, and links can be broken. If something seems wrong, please feel free to comment or contact me and I'll update the post.
I’ve been a long-time user of Subversion – and I really like the project. However, I recently switched to Bazaar for nearly all of my work, and I’d like to explain some of the reasons behind this. First of all, for those who are not familiar with Bazaar: Bazaar is a distributed versioning system built by Canonical, the same guys that created Ubuntu. It’s written in Python, and runs on Windows, Linux and Mac OS X. The UI is very consistent, as it is written with Qt, so you can easily switch between systems. As I said, it’s distributed, which is a major differences to centralised versioning systems like Subversion or Perforce. Centralised systems store the history – like the name implies – at a central location. If you run log or diff, this central location has to be reachable. The clients store only the current revision and have to query the server for many operations.
Distributed systems on the other hand don’t require a central server at all. Instead, they store all history at each client. That is, you can work locally all the time and you never have to connect somewhere. It’s likely that you will have some location to which you push your changes so they can be easily discovered by your co-developers, but this is by no means required. Many modern versioning systems are distributed, like git, Mercurial and Bazaar.
Why you should prefer a distributed system
Distributed systems have some advantages over central systems, specifically:
- Working offline is easy: You can do all your work locally, revert, query the logs, diff, without network access. That’s really cool if you are not online or your server is unreachable.
- Simple branching: Branching is typically very efficient and well supported in distributed systems, as it’s a core part of them. Merging is usually much more flexible as well.
- Easy backup: Every developer has a full backup available all the time, so if your server explodes, nothing is lost at all.
Of course, there are some disadvantages as well:
- It may be more difficult to know which copy is the “latest”. Usually, a server is still running somewhere to which all developers push or which gets the latest changes merged to, but you have to agree on this. That’s simply an organisational issue.
- Local history can become huge, especially when you store binary files. If you’re about to store binary data, a central system is usually superior.
Bazaar
I’ve tried git, Mercurial and Bazaar, and I stuck with the latter. Feature-wise, they are all very similar. Git is more low-level than the others, so it might be easier to hack something together with git, but for day-to-day use, I didn’t find a killer feature in any of them. Performance-wise, git is the fastest, but that’s only relevant if you do benchmarking. For the projects I work on, Bazaar and Mercurial are fast enough, as the response time for most commands is less than a second. Most of the time, you’re going to be limited by network speed during pushing/pulling anyway, and typical commits (changing a dozen files or so) are instantaneous with all of them. One nice feature of Bazaar is the excellent interoperation with other VCS. I’ve been using Bazaar heavily against a Subversion server, and this really worked fine — much better than with git, which was very slow when importing from SVN, and each operation against the SVN server took some time as well. The nice thing when using Bazaar against SVN is that renaming/changing content is much more robust than with SVN alone — I did some large-scale refactorings with both SVN only and Bazaar against a SVN server, and using Bazaar is much more comfortable. For instance, you can rename, change content, rename again, commit, and then push to SVN without any problems, even if one of your renames only changes the case.
Right now, I’ve switched here to Bazaar for a rather big project (5 years of history and 3000 revisions), without any trouble. I’m developing from three different machines, and keeping them up-to-date was very easy. One didn’t have internet access for instance (let’s call it B), so I would pull the trunk on machine A, and pull updates to B from A — now B has internet, and I pull from trunk again, without any problems.
Another reason I like to use Bazaar is that the UI is nice, useful and consistent across all platforms. Most of the time, I actually use the UI, as it makes many operations rather easy (like selecting which file to commit, see added files, edit ignore lists …) Finally, Bazaar has corporate backing, which provides two main benefits: Someone is getting paid to write docs, so Bazaar is really well documented. The other benefit is that some developers are working full-time on Bazaar, which means that bugs, suggestions, and other issues get eventually looked at even if they’re rather boring. With git, you don’t even have a proper way to report a bug, while you can be pretty sure that any bug you report against Bazaar gets processed some day. All in all, I would recommend to take a look at Bazaar when you are choosing a DVCS, as it might be actually all you need in an easy-to-use package with a nice, helpful community.
One side note: If you try Bazaar 2.1.0, you should get the Bazaar Explorer 1.0.0rc2, as there is a known issue with the one bundled with 2.1.0 — the toolbar is simply empty in the explorer bundled with 2.1.0.
Related posts:
You mention “interoperation with other VCS” and with Subversion in particular. If such interoperation between distributed and centralized becomes more common place and the features to support it become better, do you suppose that there may yet be a hybrid distributed/centralized VCS in the future? I ask here because you seem to be gaining some experience with the relevant use case (which I have not though this question has come to mind in the past).
I don’t think so, even though SVN has something like that on their roadmap. The key observation is here: How would this hybrid system look like?
If it allows you to work offline, and commit against a central repository, well, Bazaar for instance can do this against SVN and other stuff. The only difference here is whether you store the whole history locally, as there is one use case in which you don’t want to do this. Again, Bazaar gives you “checkouts” without history, so it can act right now as a SVN super-client (i.e. local commits, centralized development.) That’s basically what I would expect from a hybrid client — but I wonder how you think such a client would look like?
The one use case in which you don’t want history is if you have large binary blobs in your repository (game assets, for instance.) In this case, you really want a centralized system or at least store all history on the server side instead of potentially duplicating it among all your clients; and you also want to have sparse checkouts, something which is much easier with centralized clients as you don’t have to figure out which history is relevant for this subpart of your repository. This is one (and maybe the only) area where I don’t see a real distributed alternative showing up. For all other stuff, I guess most people will migrate over to DVCS over time, as it gives you lots of benefits at basically zero cost.
Small note: I also used git and mercurial, and especially with git, there is some cost in moving from a centralized system over as it has very different concepts. Bazaar on the other hand makes it very easy to switch, especially as you can configure it like SVN for the beginning (use bound branches against a central repository only) and slowly move away from this (locally branch/merge for feature development, start merging between clients, finally move branches onto the server.) The only downside here is that Bazaar does not yet provide an easy way to delete branches on the server from Bazaar itself (you have to switch to a SSH client and do it there …)
@Anteru
Well, I was glad to hear that you’ve found some useful features for interoperation, as this indicates that it’s not too tedious to be practical.
I’ve been predicting that more and more products will begin to include built-in version-control features, and I am seeing that prediction come true in a variety of products. so, I’ve been wondering how all these different tools might further interact in meaningful ways. But, I find that tools often evolve as the associated human work flows acclimate to the environments created by the tools. That is, an idea like the one that I’ve suggested won’t begin to gel until many others have the kind of work flows that call for such activities. Does that sound vague? Well, this idea is still pretty vague, and I guess that’s my point. Thanks for the response.