- Feb 20, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
A new property called _tagscache was introduced in Mercurial 2.0, so the cache wasn't actually working. The contract for tags() also changed at some point -- it stopped returning nodes that weren't in the repo. This will need to be accounted for if we start using the tags cache again. However, it isn't very clear whether the Mercurial tags cache is actually worth doing, since we already have a separate in-memory cache for Git tags in the handler.
-
- Feb 19, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
Upcoming patches will clean up some code that makes hg-git work with Mercurial versions < 2.0.
-
- Feb 20, 2014
-
-
Siddharth Agarwal authored
This is the version in Mercurial rev 87e52e642562, plus a patch to make --with-hg work for system hg (sent upstream). Importantly, this gets us the hash seed randomization we need for bugs like the one fixed by the parent commit to be detected.
-
Siddharth Agarwal authored
Previously, the correctness of _handle_subrepos was based on the order the files were processed in. For example, consider the case where a subrepo at location 'loc' is replaced with a file at 'loc', while another subrepo exists. This would cause .hgsubstate and .hgsub to be modified and the file added. If .hgsubstate was seen _before_ 'loc' in the modified/added loop, then _handle_subrepos would run and remove 'loc' correctly, before 'loc' was added back later. If, however, .hgsubstate was seen _after_ 'loc', then _handle_subrepos would run after 'loc' was added and would remove 'loc'. With this patch, _handle_subrepos merely computes the changes that need to be applied. The changes are then applied, making sure removed files and subrepos are processed before added ones. This was detected by setting a random PYTHONHASHSEED (in this case, 3910358828) and running the test suite against it. An upcoming patch will randomize the PYTHONHASHSEED in run-tests.py, just like is done in Mercurial.
-
Siddharth Agarwal authored
durin42 expressed a desire for this function to be at the top level.
-
- Feb 19, 2014
-
-
Siddharth Agarwal authored
Since a fresh GitHandler is no longer created for every commit, this speeds up the {gitnode} template massively. For a repo with over 50,000 commits, the command hg log -l 10 --template '{gitnode}\n' speeds up from 2.4 seconds to 0.3.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
Also drop the GitHandler import. All this now lives on hgrepo.
-
Siddharth Agarwal authored
Previously we'd load the git and hg maps twice on separate git handler objects. This avoids that. For a repo with over 50,000 commits, this brings a no-op hg pull down from 2.45 seconds to 2.37.
-
Siddharth Agarwal authored
Currently we call hgrepo.tags() separately for each tag. (This should be fixed at some point.) This avoids initializing a separate git handler for each tag. For a repository with over 150 tags, this brings down a no-op hg pull by 0.05 seconds.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
This and upcoming patches have the goal of initializing a GitHandler just once for a Mercurial repo.
-
Siddharth Agarwal authored
Any commit in _map_git is already known, so there's no point walking further down the DAG. For a repo with over 50,000 commits, this brings down a no-op hg pull from 38 seconds to 2.5.
-
Siddharth Agarwal authored
getnewgitcommits() does a weird traversal where a particular commit SHA is visited as many times as the number of parents it has, effectively doubling object reads in the standard case with one parent. This patch makes the convert_list a cache for objects, so that a particular Git object is read just once. On a mostly linear repository with over 50,000 commits, this brings a no-op hg pull down from 70 seconds to 38, which is close to half the time, as expected. Note that even a no-op hg pull currently does a full DAG traversal -- an upcoming patch will fix this.
-
Siddharth Agarwal authored
This wasn't obvious to me at first.
-
- Feb 16, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
For a repo with over 50,000 commits, this brings down the computation of 'export' from 1.25 seconds to 0.25 seconds. To scale this to hundreds of thousands of commits, one solution might be to maintain the mapping in a DAG data structure mirroring the changelog, over which findcommonmissing can be used.
-
- Feb 13, 2014
-
-
Siddharth Agarwal authored
Now that _handle_subrepos can handle .hgsubstate being removed, we should use it for that. The test changes make sure that the SHAs roundtrip.
-
Siddharth Agarwal authored
A test for this will be included in an upcoming patch.
-
Siddharth Agarwal authored
An upcoming patch will introduce similar variables for self._ctx. This helps disambiguate.
-
Siddharth Agarwal authored
This code will be used in multiple contexts in an upcoming patch.
-
Siddharth Agarwal authored
This will be used by _handle_subrepos in an upcoming patch.
-
- Feb 16, 2014
-
-
Siddharth Agarwal authored
-
- Feb 13, 2014
-
-
Siddharth Agarwal authored
We now also test: - removing one submodule but not all of them - replacing a submodule with a file - replacing a file with a submodule
-