Of course, repo.bzr is your old bzr repository here, while repo.git is your newly created git repository. The fast-export/fast-import commands convert the repository’s history from bzr to git. To populate our directory with the bzr repository’s files, however, we also need to perform a hard reset. If you need to convert multiple bzr branches to git, have a look at this post.
I started experimenting with distributed version control systems (DVCS) while working on my MSc thesis (around 2005). I originally maintained Cassowary.net using darcs (a DVCS written in Haskell), and switched to bzr later. Back in the early days of Uiml.net, we used CVS, which was horrible at moving or renaming files, not to mention the inability to work offline and still commit your work.
I preferred darcs and bzr over git at the time because they were a lot easier to use. These days, git seems to have catched up to bzr in that regard. Back in 2006, I also did a few performance tests and found that bzr was a lot slower than git. Things seem to have improved somewhat, but git is still The King of Speed. Oh, and GitHub is great!
I was curious to see if things changed. It seemed that both systems have improved in speed, but there were no shocking results.
There are some differences between our experiments though. Jordan wonders how long it took for me to commit my changes after adding. In fact, I didn’t do that directly but did a diff before committing. I don’t know why, I think I just forgot to commit. This clearly showed the big difference between bzr and git before and after committing. Bzr was a lot faster than git before committing, while git outperforms bzr after committing. I guess this is because git makes heavy use of data structures created during a commit.
Bzr took almost 4 minutes to diff after committing, while git only took about a second. This clearly showed a problem with bzr, it started walking the entire tree again, while git could immediately see that nothing changed. Bzr exacerbated the same problem when performing a status, it was unnecessarily slow. Jordan’s tests showed that the status problem was solved, but doing a diff when nothing has changed is still a major performance issue on big trees.
Committing a small change was a lot faster for both git and bzr. And it should! This is after all a really common operation.
I spent some time yesterday to update the Uiml.net homepage:
We set up a wiki somewhere last year to provide more information about our UIML research. However, since Uiml.net is the main focus of our research efforts, I reorganized the wiki to be more of a homepage for Uiml.net, while still listing our publications.
I am hoping to migrate all the content of the old website (still located at Kris’ homepage) to the wiki soon.
Lately I have been enjoying Launchpad for hosting my projects and Bazaar branches. It has integrated specifications (_blueprints_), bug tracking, some kind of forum (_answers_). I have moved Uiml.net over to Launchpad as well. Launchpad’s integration of Bazaar branches will be useful for managing multiple experimental contributions from myself, Kris or our Bachelor’s or Master’s students.
Finally I’m hoping to put out a more or less stable release of Uiml.net by September. More information can be found at Launchpad.
Although I am more of a bzr advocate (for one because it’s easier to use, and fast enough for me), he gives a good explanation for the need for distributed revision control (which both bzr and git belong to).