Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 Nov 2017 01:21:10 -0500] rev 35179
largefiles: explicitly set the source and sink types to 'hg' for lfconvert
I stumbled into this prior to adding the type indicator on the source and sink,
but there's no reason to try to infer the types for this conversion.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 22 Nov 2017 22:38:50 -0500] rev 35178
lfs: add a repo requirement for this extension when converting to lfs
This covers both the vanilla repo -> lfs repo and largefiles -> lfs conversions.
The largefiles extension adds the requirement directly, because it has a
dedicated command to convert. Using the convert extension is better, because it
supports more features.
I'd like ideas about how to ensure that converting away from lfs works on all
files. (See comments in test-lfs.t)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 26 Nov 2017 14:59:39 -0500] rev 35177
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 35176
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 35175
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.
Kevin Bullock <kbullock@ringworld.org> [Fri, 01 Dec 2017 13:49:47 -0600] rev 35174
Added signature for changeset
a92b9f8e11ba
Kevin Bullock <kbullock@ringworld.org> [Fri, 01 Dec 2017 13:49:46 -0600] rev 35173
Added tag 4.4.2 for changeset
a92b9f8e11ba
Mark Thomas <mbthomas@fb.com> [Fri, 24 Nov 2017 12:53:58 -0800] rev 35172
merge: check created file dirs for path conflicts only once (
issue5716)
In large repositories, updates involving the creation of many files check the
same directories repeatedly in the wctx manifest. Move these checks out to a
separate loop to avoid repeated checks hitting the manifest.
Differential Revision: https://phab.mercurial-scm.org/D1226