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.

enjoy,
Charles.

Version control: Autopia vs. off-roading

When I was a kid, it was cool to go to Disneyland and ride the Autopia ride. For those of you unfamiliar with it, you get to "drive" a car along a track. As I recall, you get a gas pedal, and the steering worked for about plus-or-minus a foot off the center-line of the track. It is a far cry from driving a real go-cart let alone a real car on the highway or going off-roading (not that I've ever intentionally been off-roading.) Comparing traditional centralized version control systems to distributed version control systems is a bit like autopia vs. off-roading.

With a centralized version control system (VCS), your options are limited, and to a certain extent that can be a good thing. A critical difference between Autopia and a centralized VCS, is that the VCS actually goes somewhere - your code line continues to move forward and doesn't loop back to the starting point.

A distributed VCS (DVCS) can follow the exact same path that a cetralized VCS provides/requires - just like you could drive a 4x4 along the Autopia track. With a DVCS tool like Mercurial, you can implement policies that end up following the same trajectory as you would with Subversion. You have one "master" repository; everyone checks out from it; everyone commits directly to the central repo; the only branching is officially sanctioned, and it occurs in master repo. And that's fine for a lot of applications. Also, some organizations want to operate on the straight and narrow, which is fine if it works for them.

As I mentioned before, I think Mercurial is very simple to use on that path. But, the blessing or curse or fun or power of a DVCS is that you need not follow that track. You can go off the track. Doing so might be the fastest way to get where you're going. Or, you might end up in the weeds. And, you can drive back onto the main road. Developers can head off in some strange direction in their private repo, share their changes with other repos, bring in changes from other repos, abandon their work, or merge it all back into the designated "main" repo. All the while, they have a real VCS tracking their work and saving it - not just random hacking in a random directory.

If Autopia is where you want to be, more power to you. I wouldn't recommend using a DVCS in that environment. Although I don't go seriously "off-road" in my development, I like to have the option to get a little mud on the tires. And even if I'm "driving on the track" and using Mercurial like a centralized VCS, I like to clone a tree onto my laptop to operate disconnected for an extended period, which is something that's not generally possible with traditional VCSs.

My most "extreme" use of Mercurial to-date has been to mirror a P4 repository that I only have intermittent access to. Hg lets me do all my work without having to get the admin to let me onto the P4 repo from by dyanamic IP address. Before that, I would work for weeks without checking in, which makes me nervous. Due to some ignorance and poor planning, I created a bit of a mess in my hg development repo, but I was able straighten it all out, build a series of mq patches, stage them on another repo, and push them back to the P4 tree.

Configuring TortiseMerge for use with Mercurial

I've been using Mercurial primarily on a Mac, but also on a Windows box for a client. Since the Windows box isn't my primary platform, it tends to be under-configured/under-tricked-out. After my first conflicted hg merge, it was time to set up a merge program.
I guess Mercurial looks through the registry where it was finding some wacked out description for P4 merge. (The client currently uses P4.) It was referring to some path that didn't exist.
I have TortiseSVN on the machine from work for a different client, so I figured I'd use that merge program. Googling around, I didn't find an example, so here you go (even though it's not real hard - see MergeToolConfiguration for details):

[ui]
merge=TortoiseMerge
[merge-tools]
TortoiseMerge.executable=C:\Programs\TortoiseSVN\bin\TortoiseMerge.exe
TortoiseMerge.args=/mine:$local /theirs:$other /base:$base -o /merged:$output

enjoy,
Charles.

DVCS (Mercurial) for Students

I just had a bit of an epiphany for yet another reason why distributed version control systems (DVCS) like Mercurial rock. In an advanced software engineering class (e.g., a capstone project), it would be appropriate to have project teams using a SCM/VCS tool. At my campus, we've never pushed that because it can be a pain to set up a server for students to access. Gotta have a dedicated host for it. Firewalls have to be open. Permissions and users have to be set up. Yada, yada, yada.

However, with a DVCS tool like Mercurial, it would be trivial and wouldn't require any networking at all. Students could use the modern equivalent of SneakerNet: ThumbNet. Put the whole repo on a thumb drive, meet up with your project partners, push and pull, done. Or, if the project is small enough - just email whole repos around. In this context, "distributed" also means you don't need any support from The Man, and that's a good thing.

For better or worse, I don't teach those classes, but if I did....


Charles.

Very non-intuitive error message from SVN

I just got the following error message out of Subversion (on the command line under Linux):


sh: ./svn-commit.tmp: Permission denied
svn: Commit failed (details follow):
svn: system(' svn-commit.tmp') returned 32256


It sounds like a file permission problem, but I couldn't find any problems - I was working in my own directory that I checked out of SVN. I ran strace to see what was going on, and right about the time that the Shinola hit the fan, I could see that it was trying to fire up an editor for the check-in comment. I looked, and I did not have the EDITOR environment variable set. Once I set it, it worked fine.

Let's see, "Permisssion denied" means that an environment variable was not set. Sure, that makes sense - NOT.

enjoy,
Charles.