Mads Kiilerich <madski@unity3d.com> [Mon, 28 Jan 2013 15:19:44 +0100] rev 18485
tests: better test coverage of largefiles localstore verify
This demonstrates problems that will be fixed later.
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Jan 2013 15:19:44 +0100] rev 18484
largefiles: adapt remotestore._getfile to batched statlfile
9e1616307c4c introduced batching of statlfile, but not all codepaths got
converted.
_getfile gave _stat garbage and got garbage back. The garbage didn't match the
expected error codes and was thus interpreted as success. It could thus end up
trying to fetch a largefile that didn't exist.
Instead we now pass _stat valid input and handle both correct and invalid
output correctly.
This makes the code work as intended ... but it would probably be better if it
didn't abort on missing largefiles, just like it happened to do before.
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Jan 2013 15:19:44 +0100] rev 18483
largefiles: don't allow corruption to propagate after detection
basestore.get uses util.atomictempfile when checking and receiving a new
largefile ... but the close/discard logic was too clever for largefiles.
Largefiles relied on being able to discard the file and thus prevent it from
being written to the store. That was however too brittle. lfutil.copyandhash
closes the infile after writing to it ... with a 'blecch' comment. The discard
was thus a silent noop, and as a result of that corruption would be detected
... and then the corrupted files would be used anyway.
Instead we now use a tmp file and rename or unlink it after validating it.
A better solution should be implemented ... but not now.
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Jan 2013 15:19:44 +0100] rev 18482
largefiles: adapt verify to batched remote statlfile (issue3780)
9e1616307c4c introduced batching of statlfile, but not all codepaths got
converted.
'hg verify' with a remotestore could thus crash with
TypeError: 'builtin_function_or_method' object is not iterable
Also, the 'hash' variable was used without assigning to it. Don't use variable
names that collide with Python built-in functions. Instead we use 'expecthash'
as in localstore.
The tests for this issue covers an untested area. The tests happens to also
reveal incorrect attempts at getting non-existing largefiles, bad server side
handling of that, and corruption issues - all to be fixed later.
Mads Kiilerich <madski@unity3d.com> [Mon, 28 Jan 2013 15:19:44 +0100] rev 18481
largefiles: let wirestore._stat return stats as expected by remotestore verify
- preparing for fixing verify crash.
Kevin Bullock <kbullock@ringworld.org> [Sun, 27 Jan 2013 11:39:51 -0600] rev 18480
tests: improve description of hgweb secret bookmarks test
Added in 886936ecc21b with only an issue number to describe it.
Kevin Bullock <kbullock@ringworld.org> [Sun, 27 Jan 2013 11:29:14 -0600] rev 18479
bookmarks: show active bookmark even if not at working dir
If the active bookmark doesn't point at a parent of the working dir
(e.g. a pull moved it out from under us), we nonetheless show it as
active. This follows on 2096e025a728 in removing the dichotomy (at least
in the UI) between "current" and "active" bookmarks.
Kevin Bullock <kbullock@ringworld.org> [Fri, 25 Jan 2013 11:43:54 -0600] rev 18478
hgweb: don't attempt to show hidden bookmarks (issue3774)
localrepository._bookmarks is unfiltered, but hgweb gets a filtered
repo. This fixes the resulting traceback on the 'bookmarks' page.
Kevin Bullock <kbullock@ringworld.org> [Fri, 25 Jan 2013 14:50:18 -0600] rev 18477
hgweb: fetch tipmost unfiltered rev thru the changelog
This fixes a traceback when tip is filtered (e.g. because it's secret).
See issue3783, for which this is a partial fix.
Kevin Bullock <kbullock@ringworld.org> [Fri, 25 Jan 2013 16:11:16 -0600] rev 18476
help: update verbose 'clone' help to include '@' bookmark
Kevin Bullock <kbullock@ringworld.org> [Fri, 25 Jan 2013 11:38:54 -0600] rev 18475
tests: fix test-help.t for '@' bookmark documentation
e031e10cdc06 unexpectedly introduced bookmarks into the results for 'hg
help -k clone'. Mea culpa, miserere &c.
Kevin Bullock <kbullock@ringworld.org> [Fri, 25 Jan 2013 11:06:30 -0600] rev 18474
help: document '@' bookmark in 'help bookmarks' and 'help clone'
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 23 Jan 2013 22:52:55 +0900] rev 18473
revset: evaluate sub expressions correctly (issue3775)
Before this patch, sub expression may return unexpected result, if it
is joined with another expression by "or":
- "^"/parentspec():
"R or R^1" is not equal to "R^1 or R". the former returns only "R".
- "~"/ancestorspec():
"R or R~1" is not equal to "R~1 or R". the former returns only "R".
- ":"/rangeset():
"10 or (10 or 15):" is not equal to "(10 or 15): or 10". the
former returns only 10 and 15 or grater (11 to 14 are not
included).
In "or"-ed expression "A or B", the "subset" passed to evaluation of
"B" doesn't contain revisions gotten from evaluation of "A", for
efficiency.
In the other hand, "stringset()" fails to look corresponding revision
for specified string/symbol up, if "subset" doesn't contain that
revision.
So, predicates looking revisions up indirectly should evaluate sub
expressions of themselves not with passed "subset" but with "entire
revisions in the repository", to prevent "stringset()" from unexpected
failing to look symbols in them up.
But predicates in above example don't so. For example, in the case of
"R or R^1":
1. "R^1" is evaluated with "subset" containing revisions other than
"R", because "R" is already gotten by the former of "or"-ed
expressions
2. "parentspec()" evaluates "R" of "R^1" with such "subset"
3. "stringset()" fails to look "R" up, because "R" is not contained
in "subset"
4. so, evaluation of "R^1" returns no revision
This patch evaluates sub expressions for predicates above with "entire
revisions in the repository".
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 19 Jan 2013 04:08:16 +0100] rev 18472
test-rebase: add another test for rebase with multiple roots
This test the case when a Merge is dropped.
Kevin Bullock <kbullock@ringworld.org> [Mon, 21 Jan 2013 13:47:10 -0600] rev 18471
update: update to current bookmark if it moved out from under us (issue3682)
If the current bookmark (the one listed in .hg/bookmarks.current)
doesn't point to a parent of the working directory, e.g. if it was moved
by a pull, use that as the update target instead of the tipmost
descendent.
A small predicate is (finally) added to the bookmarks module to check
whether the current bookmark is also active.