largefiles: allow the archiving of largefiles to be disabled
There are currently no users of this, but it is a necessary step before
converting extdiff to use archive. It may be useful to add an argument to
extdiff in the future and allow largefiles to be diffed, but archiving
largefiles can have significant overhead and may not be very diffable, so
archiving them by default seems wrong.
It is a mystery to me why the lfstatus attribute needs to be set on the
unfiltered repo. However if it is set on the filtered repo instead (and the
filtered repo is passed to the original command), the lfstatus attribute is
False in the overrides for archival.archive() and hgsubrepo.archive() when
invoking the archive command. This smells like the buggy status behavior (see
67d63ec85eb7, which was reverted in df463ca0adef). Neither the status nor
summary commands have this weird behavior in their respective overrides.
$ hg init test
$ cd test
$ echo foo>foo
$ hg addremove
adding foo
$ hg commit -m "1"
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
1 files, 1 changesets, 1 total revisions
$ hg clone . ../branch
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ../branch
$ hg co
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo bar>>foo
$ hg commit -m "2"
$ cd ../test
$ hg pull ../branch
pulling from ../branch
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
1 files, 2 changesets, 2 total revisions
$ hg co
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat foo
foo
bar
$ hg manifest --debug
6f4310b00b9a147241b071a60c28a650827fb03d 644 foo
update to rev 0 with a date
$ hg upd -d foo 0
abort: you can't specify a revision and a date
[255]
$ cd ..