Matt Harbison <matt_harbison@yahoo.com> [Sun, 26 Nov 2017 14:59:39 -0500] rev 35188
convert: allow the sink object to be wrapped when the extension isn't loaded
The next patch will wrap the conversion code, in order to write out a
requirement for 'lfs' when appropriate. Wrapping convcmd.convertsink() in an
afterloaded callback works fine when the convert extension is enabled by the
user. The problem here is that lfconvert uses the convert extension, whether or
not it was formally enabled by the user.
My first attempt was to have lfs install an afterloaded callback that would wrap
the convert sink if convert was loaded, or wrap lfconvert if it wasn't. Then
the lfconvert override could install an afterloaded callback to try wrapping the
convert sink again, before calling the original lfconvert. But that breaks down
if largefiles can't load the convert extension on the fly. [1] Further, some
tests were failing with an error indicating that the size of the afterloaded
list changed while iterating it.
Yuya mentioned that maybe some bits of convert could be moved into core, but I'm
not sure where to draw that line. The convertsink() method depends on the list
of sinks, which in turn depends on the sink classes.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108038.html
Matt Harbison <matt_harbison@yahoo.com> [Wed, 22 Nov 2017 20:49:01 -0500] rev 35187
convert: save an indicator of the repo type for sources and sinks
This seems like basic info to have, and will be used shortly when deciding
whether or not to wrap the class for lfs conversions.
The other option is to just add a function to each class. But this seems better
in that the strings aren't duplicated, and the constructor for most of these
will run even if the VCS isn't installed, so it's easier to catch errors.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Nov 2017 23:43:15 -0500] rev 35186
lfs: add a repo requirement for this extension once an lfs file is committed
Largefiles does the same thing (also delayed until the first largefile commit),
to prevent access to the repo without the extension. In the case of this
extension, not having the extension loaded while accessing an lfs file results
in cryptic errors about "missing processor for flag '0x2000'". If enabled
locally but not remotely, the cryptic error message is about no common
changegroup version. (It wants '03', which is currently experimental.)
The largefiles extension looks for any tracked file that starts with '.hglf/'.
Unfortunately, that doesn't work here. I didn't see any way to get the files
that were just committed, without doing a full status. But since there's no
secondary check on adding an lfs file once the extension is loaded and a
threshold set, the best practice is to only enable this locally on a repo that
needs it. That should minimize the unnecessary overhead for repos without an
lfs file.
Yuya Nishihara <yuya@tcha.org> [Thu, 30 Nov 2017 22:32:13 +0900] rev 35185
match: remove doc about undefined behavior of visitdir()
This was added by 8545bd381504, but core matchers support visitdir() of
arbitrary locations since 2773540c3650, and verifier._verifymanifest()
doesn't seem to strictly obey the restriction.
I have no idea how important this API contract is for third-party extensions.
That's why this patch is RFC.
Augie Fackler <augie@google.com> [Thu, 30 Nov 2017 15:48:42 -0500] rev 35184
merge with stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 22 Nov 2017 22:18:06 +0800] rev 35183
hgweb: add .jshintrc with some basic rules
This file is picked up automatically by jshint, so no extra changes required in
test-check-jshint.t.
Anton Shestakov <av6@dwimlabs.net> [Wed, 22 Nov 2017 22:11:37 +0800] rev 35182
hgweb: look up "URLSearchParams" in "window" to work around jshint issues
Unfortunately, current version of jshint (2.9.5) doesn't know such a global
variable and complains that it's undefined. Since this line tries to look up
URLSearchParams in a global scope (i.e. window), let's simply preface it with
"window." to work around jshint.