Showing 7 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.