- Nov 07, 2015
-
-
Pierre-Yves David authored
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.
-
- Oct 20, 2015
-
-
Pierre-Yves David authored
Using generaldelta has a meaningless impact on the capabilities string.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
- Nov 08, 2015
-
-
Durham Goode authored
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.
-
- Nov 12, 2015
-
-
Matt Mackall authored
-
- Nov 02, 2015
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
- Nov 10, 2015
-
-
Danek Duvall authored
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.
-
Anton Shestakov authored
-
- Nov 08, 2015
-
-
Matt Harbison authored
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.
-
Matt Harbison authored
Preserving the 'source' attribute of grafts started with a69a77a80900, which predates the introduction of 'intermediate-source' in 51930a7180bd 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.)
-
- Nov 11, 2015
-
-
Matt Mackall authored
-
- Nov 04, 2015
-
-
Augie Fackler authored
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
-
- Nov 11, 2015
-
-
Siddharth Agarwal authored
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.
-
Siddharth Agarwal authored
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.
-
Siddharth Agarwal authored
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.
-
- Nov 10, 2015
-
-
Siddharth Agarwal authored
We'll catch this exception for promptchoice queries to provide better error handling.
-
Siddharth Agarwal authored
We're going to test behavior with and without HGMERGE, so disable it for the test.
-
Anton Shestakov authored
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
-
- Nov 09, 2015
-
-
Siddharth Agarwal authored
In upcoming patches we're going to add more checks to the function currently named _symlinkcheck. This consolidates all those checks.
-
Siddharth Agarwal authored
This had no test coverage.
-
Matt Mackall authored
-
Matt Mackall authored
-
- Nov 07, 2015
-
-
Anton Shestakov authored
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.
-
- Nov 09, 2015
-
-
Mateusz Kwapich authored
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.
-
Steve Borho authored
-
Matt Mackall authored
-
- Nov 05, 2015
-
-
Javi Merino authored
-
- Nov 06, 2015
-
-
Matt Mackall authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
- Nov 05, 2015
-
-
Matt Mackall authored
This is the final missing piece in fully round-tripping random byte strings through UTF-8b. While this issue means that UTF-8 <-> UTF-8b isn't fully bijective, we don't expect to ever see U+DCxx codepoints in "real" UTF-8 data, so it should remain bijective in practice.
-
Matt Mackall authored
This correctly avoids the ambiguity of U+FFFD already present in the input and similar confusion by working a character at a time.
-
Matt Mackall authored
-
Matt Mackall authored
This replaces an open-coded utf-8 parser that was ignoring subtle issues like overlong encodings.
-
Matt Mackall authored
This allows us to find character boundaries in byte strings when trying to do custom encodings.
-
- Nov 07, 2015
-
-
Pierre-Yves David authored
We were missing one space on this block.
-