Implementing addremove correctly in largefiles is tricky, becuase the original
addremove function does not call into any of the add or remove function we've
already overridden in the extension. So the trick is to implement addremove
without duplicating any code.
This patch implements addremove by pulling out the interesting parts of
override_add() and override_remove() into generic utility functions, and
using those to handle the largefiles in addremove. Then a matcher is
installed that will ignore all largefiles, and the original addremove
function is called to take care of the regular files in addremove.
A small bit of monkey patching is used to make sure that remove_largefiles()
notifies the user when a file is removed by addremove and also makes sure
the removal of largefiles doesn't interfer with the original addremove's
operation of removing the standin.
This patch makes "hg remove" work the same way on largefiles as it does on
regular Mercurial files. If you try to remove an added largefile, the removal
fails and you are instead prompted to use "hg forget" to undo the add.
If a largefile is introduced on the branch that is merged into the
working copy, then 'hg status' would abort with an error like:
$ hg status
abort: .hglf/foo@33fdd332ec: not found in manifest!
The problem was that the largefiles status code only looked in the
first parent for the largefile. Largefiles are now always reported as
modified if they don't exist in the first parent -- this matches the
behavior of localrepo.status for normal files.
Operating on a non-existant file can cause both IOError and OSError,
depending on the function used: open raises IOError, os.lstat raises
OSError.
The largefiles code called dirstate.normal, which in turn calls
os.lstat, so OSError is the right exception to catch here.
$DAEMON_PIDS is used by tests to make sure there will be no leftover
processes, the cycling through ports is needed because they are not
available for a new bind that quickly on some systems.
There are not enough $HGPORT variables available for each hg serve,
so use the killdaemons script before reusing ports.
- old-style patterns without ^ were getting improperly anchored
- finditer was matching against beginning of line poorly
- \s was matching newlines
- [^x] was matching newlines
so we:
- remove earlier hacks for multiline matching
- fix unified test anchoring by adding .*
- replace \s with [ \t]
- replace [^x] with [^\nx]
- force all matches into multiline mode so ^ anchors work
This uncovers a number of test issues that are then repaired.
The code was using the size of a symlink's target, thus wrongly making symlinks
to large files into largefiles themselves. This can be demonstrated by
deleting the symlink and then doing an 'hg up' or 'hg up -C' to restore the
symlink.
This reveals a small bug: revert reports "reverting .hglf/largefile"
when it really should report "reverting largefile". I don't see an
easy fix, though (short of using ui.pushbuffer() to interfere with
revert's output).
test-largefiles.t is getting pretty big, and there's lots more to test
in lfconvert. And lfconvert is a fairly orthogonal feature to the
rest of largefiles.
This reintroduces tests for the case described by issue3066, among others:
- vanilla clients and servers should still be able to talk to largefiles
clients and servers about vanilla repos
- vanilla clients should not attempt to clone largefiles repos over http and
should report a useful error message (issue3066; this appears to work
correctly)
- vanilla clients should not attempt to clone largefiles repos over ssh, again
with a useful error message
- largefiles clients should not attempt to push largefile changes to vanilla
servers
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
- tweak wording of some error messages
- use consistent capitalization
- always say 'largefile', not 'lfile'
- fix I18N problems
- only raise Abort for errors the user can do something about
