Generaldelta changes some of the default targets for 'hg bundle'. All cases are
already properly tested but some ambiguous specifications are affected.
This impacts tests of the 'packed' feature. We can safely accept the new output
because the 'v1' format is not restricted to old revlog format, the requirements
are properly advertised to the client.
This test check the difference between various configurations we have to pin the
type of some repositories to ensure the test is still correct when we change the
default.
We want that capability to be stable in our testing. This is currently not an
issue because the set is size 1, but this will be once generaldelta related
data gets in there.
Any changes to the capabilities string was very hard to review. So we introduce two
tests. A small one that validates the format and a second one to validate the
content, where each capability is on its own line to make changes simpler to
review.
The existing retractboundary implementation computed the new boundary by walking
all descendants of all existing roots and computing the new roots. This is
O(commits since first root), which on long repos can be hundreds of thousands of
commits.
The new algorithm only updates roots that are greater than the new root
locations. For common operations like commit on a repo with the earliest root
several hundred thousand commits ago, this makes retractboundary go from
1 second to 0.008 seconds.
I tested it by running the test suite with both implementations and checking
that the root results were always the identical.
There was some discussion on IRC about the safety of this (i.e. what if the new
nodes are already part of the phase, etc). I've looked into it and believe this
patch is safe:
1) The old existing code already filters the input nodes to only contain nodes
that require retracting (i.e. we only make node X a new root if the old phase
is less than the target phase), so there's no chance of us adding a
unnecessary root to the phase (unless the input root is made unnecessary by
another root in the same input, but see point #3).
2) Another way of thinking about this is: the only way the new algorithm would
be different from the old algorithm is if it added a root that is a
descendant of an old root (since the old algorithm would've caught this in
the big "roots(%ln::)". At the beginning of the function, when we filter out
roots that already meet the phase criteria, the *definition* of meeting the
phase criteria is "not being a descendant of an existing root". Therefore,
by definition none of the new roots we are processing are descendants of an
existing root.
3) If two nodes are passed in as input, and one node is an ancestor of the other
(and therefore the later node should not be a root), this is still caught by
the 'roots(%ln::)' revset. So there's no chance of an extra root being
introduced that way either.
The cut and head utilities on Solaris have weird differences from the GNU
versions. The f helper script does a dump more nicely than those tools,
anyway.
There are make targets for building mercurial packages for various
distributions using docker. One of the preparation steps before building is to
create inside the docker image a user with the same uid/gid as the current user
on the host system, so that the resulting files have appropriate
ownership/permissions.
It's possible to run `make docker-<distro>` as a user with uid or gid that is
already present in a vanilla docker container of that distibution. For example,
issue4657 is about failing to build fedora packages as a user with uid=999 and
gid=999 because these ids are already used in fedora, and groupadd fails.
useradd would fail too, if the flow ever got to it (and there was a user with
such uid already).
A straightforward (maybe too much) way to fix this is to allow non-unique uid
and gid for the new user and group that get created inside the image. I'm not
sure of the implications of this, but marmoute encouraged me to try and send
this patch for stable.
The _filefoldmap is not updated in when files are deleted from dirstate. In the
case where the file with the same but differently cased name is added afterwards
it renders _filefoldmap incorrect. Those steps must occur to for a problem to
reproduce:
- call status (with listunknown=True),
- update working rectory to a commit which does a casefolding change (A -> a)
- call status again (it will show the file "a" as deleted)
Unfortunately I'm unable to write a test for it because I don't know any
core-mercurial command able to reproduce those steps.
The bug was originally spotted when hgwatchman was enabled. It caused the
changeset contents change during hg rebase (one file unrelarted to changeset
was deleted in it after rebase).
The hgwatchman is able to hit it because when hgignore changes the hgwatchmans
overridestatus is calling original status with listunknown=True.
Multiple threads might attempt to check links with the same temporary
name. This would cause one side to get an EEXIST error and wrongly
fail the support check. Here, we simply retry if our temporary name
exists.
The previous changeset is a simpler way of fixing issue4934 without changing the
spirit of the code. We can remove the dual call to 'delayupdate' but we keep the
tests to show that the issue is still fixed.
The 'prechangegroup' interfere with 'delayupdate' logic because it trigger the
one time call of 'changelog._writepending' (see issure4934). There is no reason
not to call that hook before setting up 'delayupdate' so we move the call a bit
earlier to avoid interference.
The try finally is here to ensure we release the just-created transaction.
Therefore we should not do half a dozen operations before actually entry the try
scope.
This option will make repositories created as general delta by default but will
not make Mercurial aggressively recompute deltas for all incoming bundle.
Instead, the delta contained in the bundle will be used. This will allow us to
start having general delta repositories created everywhere without triggering
massive recomputation costs for all new clients cloning from old servers.
General delta is currently controlled by a single option, we will introduce a
new one in the next changeset.
We extract the logic in a function while it is simple.
When running the tests with 1.7.7.6, I get 'files' and 'insertions' instead of
the singular forms, and there is also an additional '0 deletions(-)' at the end.
Since this doesn't seem important to the test, silence it.
Preserving the 'source' attribute of grafts started with 091a7dd3c7d0, which
predates the introduction of 'intermediate-source' in 7fbf0ef28408 by a year and
a half. It looks like not preserving this was an oversight.
On a related note, notice how the source value of 32af76 is no longer visible in
the graph above this test. Is it reasonable to import the sha1 translation from
evolve.py:relocate() into scmutil or similar, and use that to fixup these
attributes as well as the commit message? (I realize that evolve is still
experimental, but I don't see a way to do this from the evolve extension.)
Without a hook of this nature, narrowhg[0] clones always result in 'hg
verify' reporting terrible damage to the entire repository
history. With this hook, we can ignore files that aren't supposed to
be in the clone, and then get an accurate report of any damage present
(or not) in the repo.
0: https://bitbucket.org/Google/narrowhg
A file being missing is a completely valid situation in which the user may want
to re-resolve merge conflicts. Mercurial already maintains backups of local
data, so this turns out to be easy to handle.
Previously we'd abort the merge entirely if there was an EOF at the prompt.
This is unnecessary -- it's much better to simply fail and treat the file as
unresolved instead.
In upcoming patches we're going to be making some improvements to the ':prompt'
merge tool, and one of them is recovering appropriately from exceptions. It is
important in such cases to make sure that the merge state is written out
properly.
I went through the output and verified that it all makes sense.
Log pages, i.e. changelog, filelog and search results page computed children
and parents for each changeset shown, because spartan hgweb style shows this
info. Turns out, computing all this is heavy and also unnecessary for log pages
in all other hgweb styles.
Luckily, templates allow an easy way to do computations on demand: just pass
the heavy part of code as a callable and it will be only called when needed.
Here are some benchmarks on the mercurial repository (best of 3):
time wget http://127.0.0.1:8021/
before: 0m0.050s
after: 0m0.040s
time wget http://127.0.0.1:8021/?revcount=960
before: 0m1.164s
after: 0m0.389s
time wget http://127.0.0.1:8021/log/tip/mercurial/commands.py
before: 0m0.047s
after: 0m0.042s
time wget http://127.0.0.1:8021/log/tip/mercurial/commands.py?revcount=960
before: 0m0.830s
after: 0m0.434s
