mercurial checkout mostly broken in 0.7.6

[warner]

it turns out the short-term fix that I added for #103 caused all new hg checkouts to fail. The problem is that the 'hg clone' command does not, in general, accept a --revision argument (it can, but it requires backend support which is apparently not provided by the normal CGI server).

The symptom is that 'hg update' builds work ok, but if we ever need to do a full checkout, the checkout step fails.

I put a note in #103 to indicate that testing was still needed, but I assumed that worst-case the old code would keep working. I was wrong.

[warner]

one way to get the desired behavior is to do a normal HEAD clone or pull, followed by an 'hg update --rev REV'. That will roll back the clock to the older version, if necessary. I suspect this will also handle branches well, so maybe we can use 'pull/update' when switching branches instead of clobbering everything.

But, of course, the first step is to write some unit tests for it.

[warner]

also note, a workaround for 0.7.6 is to force a build (and *not* specify a revision number). That will do a HEAD build, which works properly. After that, everything should be fine until the buildslave wants to clobber the source tree (say, if it experiences an error).

[warner]

I was wondering why the unit tests didn't catch this, and it occurred to me that local repositories probably *do* support 'hg clone --rev', and it's just remote (i.e. HTTP) ones which do not. If that's the case, then finishing+activating the 'hg server' HTTP test should probably expose this one.

[warner]

fixed in [2ff59a053cb6ab28c7f11797859ed2f37e890f57]. with a unit test (that uses 'hg serve').

Note that if both client and server are running mercurial 0.9.2 or later, then this checkout-to-a-specific-revision actually works. The workaround in [2ff59a053cb6ab28c7f11797859ed2f37e890f57] is just to handle the case where one side or the other is too old to support this feature.