Adrian Buehlmann <adrian@cadifra.com> [Tue, 18 Sep 2012 07:58:50 +0200] rev 17605
store: add multiline doctest case for encodedir()
a followup to 64c6a0d4d4bd
Adrian Buehlmann <adrian@cadifra.com> [Mon, 17 Sep 2012 11:00:38 +0200] rev 17604
store: optimize fncache._load a bit by dirdecoding the contents in one go
For a netbeans clone on Windows 7 x64:
Before:
$ hg perffncacheload
! wall 0.124000 comb 0.124801 user 0.124801 sys 0.000000 (best of 76)
After:
$ hg perffncacheload
! wall 0.096000 comb 0.093601 user 0.078001 sys 0.015600 (best of 97)
Thomas Arendsen Hein <thomas@intevation.de> [Tue, 18 Sep 2012 17:00:58 +0200] rev 17603
wireproto: workaround for yield inside try/finally incompatible with python2.4
Matt Mackall <mpm@selenic.com> [Tue, 18 Sep 2012 16:19:56 -0500] rev 17602
merge with stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Sep 2012 12:43:24 -0400] rev 17601
largefiles: delegate to the wrapped clone command
This allows the wrapped command's validation code to run (which is currently
only to ensure 'noupdate' and 'updaterev' aren't both specified), the
copy/pasted unpacking of hg.clone() args to be removed, and any future changes
to the base command (however unlikely) to be inherited by largefiles.
Unfortunately, the command override can't be swapped entirely for an hg.clone()
override because the extra --all-largefiles arg needs to be injected. It also
isn't enough to call the wrapped clone command and leave the caching code after
it, because the file caching code needs access to the destination repo, which is
only available from hg.clone(). An alternative would be to use the dest path in
the clone command override to re-obtain a reference to the repo.
A slight deviation from the regular hg.clone() function is that the repo is NOT
deleted if the caching fails, but that was also the previous behavior. Maybe it
should for consistency?
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Sep 2012 12:09:53 -0400] rev 17600
largefiles: don't convert dest=None to dest=hg.defaultdest() in clone command
A status message is output if hg.clone() determines the default destination
because None was provided. The previous code never passed None to hg.clone().
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Sep 2012 03:37:38 -0400] rev 17599
largefiles: restore caching of largefiles with 'clone -U --all-largefiles'
This was broken when restoring normal -u and -U functionality.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 08 Sep 2012 13:31:06 -0400] rev 17598
largefiles: restore normal 'clone -u' and 'clone -U' functionality
Previously, tip would be checked out regardless of the -u or -U parameter. I'm
not sure what the 'required for successful walkchangerevs' comment meant, but it
appears to reference code which has since moved to downloadlfiles() in
7d6a660ca151. Perhaps it was to force caching when the -U parameter is given?
The price of this change is that -U --all-largefiles won't cache anything. That
will be fixed next.
Note that X + Y in the 'X largefiles updated, n removed' and 'Y additional
largefiles cached' lines do not add up to the same values in these tests, but
all of the largefiles have been downloaded. The reason being that several
largefiles have the same content (eb7338044 is pointed to by sub/large2, large3
and sub/large4). In the 'clone -u 1' operation, this largefile is cached to
populate the working directory, even without --all-largefiles. That means the
file isn't downloaded again and cached in the rev where large3 and sub/large4
both point to this file. Downloading that one file in that one rev seems to be
counted twice with 'clone -u 0'. (Maybe it is also being downloaded twice?)