Showing 14 posts
The purpose of this post is to tell you the story of the Version Control System (VCS) choices I have made while maintaining my open source projects ATF, Kyua and Lutok. It also details where my thoughts are headed to these days. This is not a description of centralized vs. distributed VCSs, and it does not intend to be one. This does not intend to compare Monotone to Git either, although you'll probably feel like it while reading the text.
Wow, it has been a long time... 5 years ago, I created the monotone-server package in pkgsrc, a package that provided an interactive script to set up a monotone server from scratch with, what I though, minimal hassle. My package did the job just fine, but past year I was blown away by the simplicity of the same package in Fedora: their init.d script provides a set of extra commands to initialize the server before starting it up, and that is it.
For a rather long while I had been able to avoid the use of the Subversion services offered by my research group even if they were omnipresent. But today, this lucky trend vanished. I have been "forced" to use one of these devilish repositories to add some of my stuff. Using this goes against my "principles", as a colleague said. If you don't know it, Subversion is a centralized version control system.
If you inspect the ATF's source code history, you'll see a lot of merges. But why is that, if I'm the only developer working in the project? Shouldn't the revision history be linear? Well, the thing is it needn't and it shouldn't; the subtle difference is important here :-) It needn't be linear because Monotone is a VCS that stores history in a DAG, so it is completely natural to have a non-linear history.
I have just merged my net.venge.monotone.help-rewrite branch into the mainline Monotone's source code. I already explained its purpose in a past post, so please refer to it to see what has changed. There is still some work to do on the "help rewrite" area, but I won't have the time to do it in the near future. Hence I added some items to the ROADMAP file explaining what needs to be done, hoping that someone else can pick them up and do the work.
I've been using Git (or better said Cogito) recently as part of my PFC and, although I don't like the way Git was started, I must confess I like it a lot. In some ways it is very similar to Monotone (the version control system I prefer now) but it has its own features that make it very interesting. One of these is the difference between local and remote branches, something I'll talk about in a future post.
A couple of weeks ago, I updated Monotone to 0.34 and noticed a small style problem in the help output: the line wrapping was not working properly, so some words got cut on the terminal's boundary. After resolving this minor issue, I realized that I didn't know what most of the commands shown in the main help screen did. Virtually all other command-line utilities that have integrated help show some form of an abstract description for each command which allows the novice to quickly see what they are about.
The last weekend of past November, Monotone's main author, Graydon Hoare, proposed a "bugathon": a time frame in which all efforts could be focused on fixing existing bugs in the code. The price for solving a bug was a T-Shirt (or any other object from its CafePress shop), so I decided to help a bit by fixing some portability bugs to NetBSD. And today, I received the long sleeved T-Shirt I ordered in exchange for the fixes :-) (Will post a photo of this one too when I learn how to do it.
The Monotone VCS provides the concept of mini-branches. A mini-branch is a lightweight branch created inside a formal branch whenever a commit causes "conflicts" with the actual contents of the repository. For example, if your working copy is not up to date and you commit something, you will create a new head within the branch (that is, a mini-branch), that you will later need to (possibly manually) merge with the other head to remove the divergence.
If you have ever examined the source distribution of an open source project, you'll probably have noticed a ChangeLog file. This file lists, in good detail, all changes done to the source code in reverse order, giving their description, the name of the affected files and the name of the author who did the change. So far, so good. But I really think that these files, or better said, the way they are written and managed, is flawed.
After explaining what is the Monotone's CVS gateway, I've been asked to post a little step by step tutorial about it. I'll focus the example towards pkgsrc. Here it goes: The first step is to create a local database for Monotone and a key for personal use: $ monotone --db=~/pkgsrc.db db init $ monotone --db=~/pkgsrc.db genkey email@example.com Once this is done, we can proceed to import the CVS repository into the database.
After a long time, I've finally decided to give Monotone's net.venge.monotone.cvssync branch a try. The code in it implements a bidirectional gateway between Monotone and CVS. What this means is that Monotone can be used for private development while working on a project that already uses CVS (doing the inverse could be... stupid?). The way it works is basically the following: first of all, you synchronize your local Monotone database with a remote CVS repository, importing the whole revision tree into it using cvs_pull.
Some weeks ago, I installed Monotone on my main machine to act as a dedicated server for Vigipac's source code. During the process, I had to write a rc.d script and configure multiple things to get everything working safely. The overall process is not difficult once you know how Monotone works, but it is quite time consuming and error prone (due to concrete file permissions, for example). So I thought I could share my work to make this process easier to other people and love pkgsrc even more ;-)
I'm amazed after having played with Monotone during the whole evening. Simply put, it is a distributed version control system, similar to CVS in the sense that it keeps track of changes across files and lets multiple people work at the same time with them. But, unlike CVS, it has many other cool features. The front page of its website contains a nice paragraph summarizing all available features, so I'm not repeating them here.