Publishing Modules in Mercurial
This is a post from Luke's old blog; it is saved here statically for historical purposes, as of October 2008
I've been doing a bit of work for a client, trying to build Puppet recipes to build and manage Rails installs (Rails, Mongrel, and Nginx). It's not exactly going smoothly, because I'm not terribly knowledgeable about any of these tools so I'm having to teach myself the tool and then teach myself how to manage it.
I'm still struggling with which version control system to use, and I've been basically behaving randomly about it. I've got a couple of modules in bzr, but for some reason I chose Mercurial for these. Given how small each module is -- they're maybe 5-7 files at most -- this isn't a very good way to figure out which SCM to use, but, well, at least I've got experience with Mercurial's stupid server tool.
This is where things got silly. Mercurial at least has a server-side "tool", but it's just a CGI, and, well, it's a crappy CGI. The docs are atrocious -- they explain how to set up your web server, and how to write the configuration file, but they recommend (apparently because SuSE has ridiculous configuration defaults) that you put your configuration file in the same directory as your CGI files. I'm not sure this is so much a security problem as it is just downright silly.
So, I modified the CGI to look in the same directory as my hg repositories. This isn't much better, but at least no one's going to accidentally attempt to execute my configuration file.
It's also silly that the CGI seems to want contact information and a description, but none of the initialization examples mention this information.
I wish one of these SCMs would just hurry up and win. Mark Shuttleworth has me kind of convinced on the importance of renaming; I recently ran into really annoying versioning problems because some moved a bunch of directories in a Subversion repository of mine, and because I had those subdirectories checked out (they were application configuration directories) I had to import manually, check it out again, and move it into place. I'm frankly not sure if bzr would have been much better, but I like to think it would.
I will say that I consider http-based serving to be a critical feature in an SCM. I don't want to have to give my developers real account access (which ssh requires), and I like how SVN makes it easy to control a given user's access to each repositry (I have a 115 line SVN auth file). This would probably be a tie-breaker for me.
In the meantime, I need to give git a spin. My new employee, Michael O'Brien, has been talking it up, and it certainly seems to get a lot more respect than the other tools (although that might just be because Linus wrote it and it's written in C instead of Python).
Expect to at least see more complaining in this space, I guess.
