Sunday, August 23, 2009

Mercurial for the Homeless

Generally, I'm not one to talk about crazy dreams. You know those ones right before you wake up that seem like a Salvador Dali painting? Anyway, I had one the other day where either I was homeless living out of a car, or I was observing someone like that. Anyway, it dawned on me in the dream that Mercurial (or any DVCS) would be perfect for that situation because I figured that the homeless person would only have intermittent network connectivity, but he still needed to get work done.
OK, maybe the part about someone living out of their car "needing" to get coding done is a bit crazy, but I already admitted that it was a weird dream. I suppose jet-setting open-source gurus might feel kinda homeless from time to time, and they do need to make use of their time on planes, so maybe it wasn't so crazy after all. And, when you get right down to it, the two use cases are more similar than different, and Mercurial and other DVCSs excel at it.
For the record, the rest of the dream was related to work I'm doing for a client converting from CVS to SVN without necessarily having shell access to the server machines. I thought of a zillion ways where I could do something trivially in Mercurial but SVN (without shell access) just kept kicking my butt. I just hope shell access comes through, so the dreams can cease.


Thursday, August 06, 2009

Problem with Hudson as a Windows Service

Setting up Hudson to run as a windows service is wicked easy. However, at a client we ran into a problem with the user that the service runs as. By default, the service runs as the Local Service (or maybe Local System) user. Also, by default Hudson runs out of the .hudson directory under the user's home directory (in Documents and Settings).

This ran fine until someone logged into the console. Hint number one that there was a problem was that Windows took forever to log the user in while there was a huge amount of disk activity. Then, suddenly Hudson reverted to its state from several weeks before - recently added users and builds were missing. Looking around I could see that many users had a .hudson directory (as well as Maven .m2 directories), which made no sense - only the Local Service user was running Hudson.

As near as I could tell, logging in on the console was somehow changing the value of the Local Service user's home directory. And for some reason, Windows thought everyone should have a .hudson directory. (Thus the long time to login - Windows was copying the Hudson directory to the new user.)

Anyway, the solution was to create a real directory for Hudson - C:\Hudson, and to point Hudson at that by setting the HUDSON_HOME environment variable. To make this as easy as possible, I just set it via the Control Panel as a system-wide environment variable. I filled the directory with the contents of the .hudson directory in my home, as it seemed to have most/all of the recent users and jobs.

Also, while fixing all of this up, I created a limited (non-administrator) user to run the service. This is just good security that was skipped when Hudson was initially set-up (by someone else) as a quick proof-of-concept prototype.