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)
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
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.
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.
This was added by cb39606d374e, but core matchers support visitdir() of
arbitrary locations since a4236180df5e, 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.
The `hg lfconvert --to-normal` command uses the convert extension internally to
work its magic, but that produced devel-warn messages if the convert extension
wasn't loaded by the user. The test in 658e7a6d93e0 (modified here) wasn't
showing the warnings because the convert extension was loaded via $HGRCPATH.
Most of the config options default to None/False, but 'hg.usebranchnames' and
'hg.tagsbranch' are supposed to default to True and 'default' respectively.
The first iteration of this was to ui.setconfig() inside lfconvert, to force the
convert extension to load. But there really is no precedent for doing this, and
check-config complained that 'extensions.convert' isn't documented. Yuya
suggested this alternative.
This partially backs out 448e09d8859d.
Repoview can have a different life cycle, causing issue in some corner
cases. The particular instance that revealed this comes from localpeer. The
localpeer hold a reference to the unfiltered repository, but calling 'local()'
will create an on-demand 'visible' repoview. That repoview can be garbaged
collected any time. Here is a simplified step by step reproduction::
1) tr = peer.local().transaction('foo')
2) tr.close()
After (1), the repoview object is garbage collected, so weakref used in (2)
point to nothing.
Thanks to Sean Farley for helping raising and debugging this issue.
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.
Variables that are used or assigned without any declaration using var (or let,
or const) are considered global. In many cases this is inadvertent and actually
causes a variable leaking to a broader scope, such as a temporary variable used
inside a loop suddenly being accessible in global scope. (This corresponds to
"undef" option of jshint).
So this patch limits the scope of variables that don't need to be global. There
are a lot of helper variables in Graph.render() used in a loop, I've declared
them all on one line to reduce patch size. "radius" is special because it
wasn't passed to graph.vertex, but was used there (it worked because this
variable leaked to global scope). "window.graph" is created by an inline script
in graph.tmpl so that it can be used in ajaxScrollInit() function, this patch
makes this fact explicit by assigning window.graph to a local variable.
"xhr" is a really widespread name for this kind of things, no idea where did
"xfr" come from (the original fbf9645839e4 doesn't explain that). Let's just
change one letter so the name makes more sense.
In JavaScript, using for-in loops to access every property of an object can
have unexpected results when inheritance is involved. For example, if some
piece of code adds a property (it may be a method too) to Object.prototype,
then all for-in loops that iterate over keys of any object (also anything that
inherits Object) will get that property on one of the iterations. To filter out
such unexpected properties for-in loops have to use Object.hasOwnProperty()
method. (This corresponds to "forin" option of jshint).
In the two first cases "data" and "edges" are arrays, to it's simpler to just
switch to using a regular for-with-a-counter loop.
This patch changes "==" (equals operator) to "===" (strict equals operator).
The difference between them is that the latter doesn't do any type coercions.
It's handy to compare string '1' to number 1 sometimes, but most of the time
using "==" is inadvertent and can be replaced by an explicit type conversion.
(This corresponds to "eqeqeq" option of jshint).
Some of the changes in this patch are straightforward, e.g. when comparing
results of typeof (they could only be strings). The same goes for 'none' and
similar strings that can't be sensibly coerced to some other type. Two changes
that compare values to "1" and "0" can be clarified: getAttribute() returns
either a string or null, but comparing null to a string is always false, so no
logic is lost.
The first hunk had a non-breaking space character just before "{", it's not an
error or anything, but let's fix it while we're at it. (This corresponds to
"nonbsp" option of jshint).
Hunks 2 and 3 change "==" (equals operator) to "===" (strict equals operator).
The difference between them is that the latter doesn't do any type coercions.
It's handy to compare string '1' to number 1 sometimes, but most of the time
using "==" is inadvertent and can be replaced by an explicit type conversion.
(This corresponds to "eqeqeq" option of jshint).
Most of this file already uses strict equals operator, and in the code affected
type coercion is not needed, because tagName and selectableTag are both strings
and endId and startId are both numbers.
We make "foo (re)" match the entire line by adding a \Z to the regular
expression before matching. However, that doesn't help when the
regular expression is something like "| foo", because that gets
translated to "| foo\Z", where the "|" has lower precedence and it
thus matches the empty string, which is of course a prefix of every
string. Fix by wrapping expression in a group before adding the \Z to
the end.
Differential Revision: https://phab.mercurial-scm.org/D1546
Due to a bug in the test runner (fixed by the next commit), the regex
used for matching lines like " foobar | 2 +-" stoppped at the "|" and
the test passed even though the rest of the line did not match. The
test seems to have been supposed to match "|" and "+" literally on
those lines, so this changes the regex to escape those characters. It
also changes a "\s*" to "\s+" since I think we'll always include a
space after the "|" in the diffstat output.
Differential Revision: https://phab.mercurial-scm.org/D1545
This should fix most of the failing tests on the FreeBSD builder,
since it has no 127/8 series IP as a side effect of being trapped in a
jail.
Differential Revision: https://phab.mercurial-scm.org/D1552
The original tests (kanji and null) in test-hgweb-commands.t come from
6213c4c3d3f7 and f18359d4ac5a, but they check json escape filter by using
JavaScript variable on /graph page, which is awkward, and I'm planning to
remove commit description from this variable soon. Let's move the parts that
check json template filter to a more appropriate file and use normal json-*
templates.
Apparently '$!' doesn't return a Win32 PID, so the process was never killed, and
the next run was screwed up. Oddly, without the explicit killdaemons.py at the
end, the test seems to hang. This spawning is just sad, so I limited it to
Windows.
mercurial.js has a process_dates() function that calculates relative age for a
given date, it works for all elements with "age" css class. If those elements
also have "date" css class, the original text is preserved and age is added at
the end.
This patch adds these two css classes in some pages in gitweb and monoblue that
weren't already using this feature.
Changectx are expensive and not needed there. The use of `repo.set` denote old
code that predate the introduction of `repo.revs` that we now use.
On my mercurial repository 495 draft:
before: 0.054239 second
after: 0.046935 second
On a mercurial repository with 115973 draft:
before: 0.564548 second
after: 0.130534 second
Changectx are expensive and not needed there. The use of `repo.set` denote old
code that predate the introduction of `repo.revs` that we now use.
On my mercurial repository 495 draft:
before: 0.010275 second
after: 0.008832 second
On a mercurial repository with 115973 draft:
before: 0.899255 second
after: 0.397131 second
Clicking on a line link on pages that show any kind of file contents (including
diffs) should highlight that line, and in monoblue it works when there's a
<pre> element (e.g. diff), but pages that use <table> element (annotate and
compare) need this css class. It matches and highlights linked (":target")
table rows. This line is pretty much copied from gitweb theme.
There's a visual difference in hgweb between one changeset that is the tip of
its branch and another that simply belongs to that branch. But paper theme
ignored this difference on changeset page and used to always use "branchname"
css class, be that changeset the tip of its branch or not. That has been
recently fixed, so this piece of css is not needed anymore.
Let's make "instabilities" list contain items with "instability" key as opposed
to "name" key. This way it's more explicit and more consistent with the log
command-line template.
We can avoid a SPACE(len(changelog)) allocation by using a defaultdict.
Test Plan:
python run-tests.py test-bisect*
Differential Revision: https://phab.mercurial-scm.org/D1499
Since we have revsets we can be more concise in doing the ancestor calulcation.
Significant commits are all descendent of the topmost good commits.
Test Plan:
python run-tests.py test-bisect*
Differential Revision: https://phab.mercurial-scm.org/D1498
Pass repo into the bisect function to get more flexibility in what we can call.
This will allow us to use revsets to rewrite parts of the ancestor and children
calculation in later patches.
Test Plan:
python run-tests.py test-bisect*
Differential Revision: https://phab.mercurial-scm.org/D1497
Previously, if the develwarn call site did not specify the category of warning,
and devel.all-warnings was False, it would emit the warning. If it was
intended that this emit a warning if config is unspecified, I would have
expected a comment, so I assumed this was unintentional and am changing the
behavior.
Differential Revision: https://phab.mercurial-scm.org/D1494
Before, early options were stripped from args, and because of this, some
kind of parsing errors weren't reported. For example,
$ hg ci -m -Ra file
would execute "hg ci -m file" in repository "a".
This patch fixes the issue by parsing early options again by real getopt-based
parser, and verifying the results. If the early parsing appears wrong, hg just
aborts. The current error message seems not nice, and should be improved, maybe
in V2 or follow-up.
Note that this isn't a security feature because we can still do anything by
using shell aliases.
So we can easily compare it with the corresponding getopt() result.
There's a minor behavior change. Before, "hg --cwd ''" failed with ENOENT.
But with this patch, an empty cwd is silently ignored. "hg -R ''" has always
worked as such, so -R has no BC.
This allows us to parse the original args later by full-blown getopt() in
order to verify the result of the faulty early parsing. Still we need the
'strip=True' behavior for shell aliases.
Note that this series is RFC because it seems to change too much to be
included in stable release.
