largefiles: defer lfdirstate.drop() until after commit (
issue3364)
The example in comment #9 of the bug writeup must be run exactly- it was the
commit after the rm and prior to the addremove that screwed things up, because
that commit noticed that the largefile was missing, called drop(), and then the
original commit function did nothing (due to the file in the '!' state). The
addremove command properly put it into the 'R' state, but it remained stuck in
that state (because commit insisted 'nothing changed'). Without the commit
prior to addremove, the problem didn't occur.
Maybe this is an indication that lfdirstate needs to take a few more hints from
the regular dirstate, regardless of what _it_ thinks the state is- similar
inconsistency is probably still possible with this patch if the original commit
succeeds but the lfdirstate write fails.
largefiles: fix addremove with -R option
If a file was missing, the missing list contained a path relative to the repo.
When building the matcher from that list, the file name ended up concatenated to
cwd, causing the command to abort with '<file> not under root'. This rebuilds
the missing list with paths relative to cwd.
dispatch: fix traceback when extension was tested with newer versions only
The "worst" extension still is the one tested with the lowest tested version
below the current version of Mercurial, but if an extension with was only
tested with newer versions, it is considered a candidate for a bad extension,
too. In this case extensions which have been tested with higher versions of
Mercurial are considered better. This allows finding the oldest extension if
ct can't be calculated correctly and therefore defaults to an empty tuple, and
it involves less changes to the comparison logic during the current code
freeze.
test-extension.t: use fixed version string instead of current tag
Currently tests break with the current tag being 2.3-rc and tags set by the
user could affect this test, too.
Added tag 2.3-rc for changeset
a06e2681dd17