Just when I was just starting to get comfortable with svn, along comes bzr.
svn has a lot of benefits over cvs. For me, the biggest benefit is the increased ability to work on a plane I can do an svn delete or an svn diff while disconnected. When I land, I can simply do an svn update and an svn commit.
It looks like bzr intends to take this to the next level, I can work on multiple changes, create branches, and query the version history while offline.
At the moment, it appears that the online documentation is out of synch (ahead of!) the working code.
My development is on Ubuntu. I’m currently running Breezy. Version 0.1.1 is available in that distribution via:
sudo apt-get install bzr
Dapper has 0.7.0-2, which Breezy users can get by adding the following to /etc/apt/sources.list:
deb http://mouth.voxel.net/~dilinger/bzr/breezy/ ./
And then doing:
apt-get install bzr
It appears that the next version will have a number of command alias that are more familiar to cvs/svn users, but for the meanwhile, the following works:
bzr get http://www.gnome.org/~jdub/bzr/planet/devel/trunk/ planet
If I then cd into the planet directory, I can then do:
The response is a satisfying “Nothing to do”. I can then proceed to make arbitrary changes to any source file and commit the changes. No permission necessary.
This is where it gets mind-blowing. After I am done development on my laptop, I can then simply scp/rsync my entire directory structure up to intertwingly. I can then run from my directory. That’s not the surprising part. That’s entirely to be expected.
What’s cool is that I — or anybody else — can then do a bzr get against that directory to retrieve everything - including the version history. And I had to install nothing to make this work. It is all HTTP GET of statically served files. Sweet.
In lieu of posting patches to the development list, I can simply post a pointer to my repository, perhaps with some prose indicating why anybody might care. Maintainers of other repositories may chose to merge in a portion of my changes, or they may not.
This style of development, with a low barrier to entry, is not for everyone. In fact, I’m not yet sure that it is for me. But it certainly has got me thinking.
This comment is way too typical for me to post it... but I couldn’t help to...:
Darcs can be found at [link] and for my personal projects, it is fantastic. It is easy to use, it makes smart decisions about what files should be ignored, and it keeps all of its metadata in a single directory. Another interesting feature is that it does not keep revision numbers. You can apply and remove patches in any order, provided they do not create a conflict. To make things even more interesting, it is decentralized, meaning every working copy is a full-fledged branch.
I am only using Darcs for my personal projects, and I am using svn for PLANET ARGON development projects. It should be noted, however, that Dave Fayram, a member of the Ruby community, is working on establishing patterns for groups using Darcs.
IMHO what’s really needed (for all the DVCS’s) is a how-to-pretend-you-are-using-svn document. A number of them have a for-cvs-users document, which isn’t that useful because there’s so much opportunity to harp about CVS’s many nuisances that the author misses all the interesting/hard things. And most documents only get you as far as pretending you are using svn on a local repository, which isn’t very interesting anyway.
If Darcs people can document patterns for doing svn-like development, that would be really really useful. I think the DVCS people need to start by showing how to do everything people have become comfortable with in svn, and only then start showing the new and interesting things you can do with the new model. Subversion used that model of introduction with great success.
It’s still a bit rough, but I like using svk for a decentralized VCS. For me it’s major usefulness comes from it’s being built on top of and compatible with svn, so I can do serious work offline with projects that use svn. These days, that’s most of them.
Sam Ruby discusses bzr, a distributed version control system and in the comment section you can find a number of other recommendations: bzr Darcs Mercurial SVK - a distributed version control system based on Subversion Two interesting readings...
Jon> I’ve never managed to figure out arch/tla/bazaar/bazaar-ng/bzr, the sheer number of implementations has scared me off.
I think you are a bit confused.
GNU Arch is a (the first?) distributed VCS, it’s essentially a protocol. tla is the current GNU branch (previously maintained by Tom Lord, and now by Andy Tai), written in C. baz (or Bazaar1) was a fork of tla (driven by Canonical).
Bazaar-NG (or Bazaar2) is a completely different design, coming from (mostly) the people who worked on baz, written in Python. bzr is the name of the Bazaar-NG command.
So, two fundamentally different DVCS: Arch (tla, baz), and Bazaar-NG (bzr).
(for the sake of simplicity, I’m leaving out the other historical or still maintained forks of GNU Arch)
Just to let everybody know — I’m enjoying this conversation.
My coming into contact with bzr was entirely accidental. I was simply looking to find a web based, river of news style aggregator that Simply Worked, and bzr happens to be the revision control system of choice for PlanetPlanet.
Interesting. The HTTP GET thing is fantastic. That’s been something that’s been annoying me about SVN and company for awhile now. I’ve been hearing lots of good things about darcs and mercurial and others, but I just haven’t had the time to play with source control systems since SVN works just fine for almost everything I do. I’ve been meaning to write a CMS of sorts built on top of a quality source control system though.
Out of curiosity, how well do each of the various source control systems deal with massive repositories (think several terabytes)? And which ones have HTTP GETable urls for all of the files under source control that allow the files to be loaded directly from a browser? Also, which have interfaces that won’t give me a horrendous headache if I try to access them from within a Rails app?
I’ve also just recently discovered bzr and am currently somehow in a fight with myself: I like bzr esp. because it’s easy to install, extensible and written in a language I know, so hacking it up a little bit shouldn’t be a problem.
But on the other side I have darcs, which comes with the absolute killer feature for me: `darcs send` lets you extract certain patches and email them to another maintainer. You can also simply store this changeset as a file and send it yourself :)
From what I can see so far, bzr doesn’t have something like that yet, although it’s planed from what I can tell.
But darcs also comes with a big disadvantage for me: Installation on a Mac sucks thanks to Haskell, which is just a pain to compile and install. You also need darcs to be installed on the server to sftp your repository up.