- Mar 25, 2014
-
-
durin42 authored
Tests pass on both my Mac and Linux machine, so I feel moderately confident that this is portable.
-
Siddharth Agarwal authored
Previously, whenever a tree that wasn't the root ('') was stored, we'd prepend a '/' to it. Then, when we'd try retrieving the entry, we'd do so without the leading '/'. This caused data loss because existing tree entries were dropped on the floor. Fix that by only adding '/' if we're adding to a non-empty initial path. This wasn't detected in tests because most of them deal only with files in the root and not ones in subdirectories.
-
- Mar 15, 2014
-
-
Siddharth Agarwal authored
Previously, we'd spin up the Mercurial incremental exporter from the null commit and build up state from there. This meant that for the first exported commit, we'd have to read all the files in that commit and compute Git blobs and trees based on that. The current Mercurial to Git conversion scheme makes most sense with Mercurial's current default storage format, where manifests are diffed against the numerically previous revision. At some point in the future, the default will switch to generaldelta, where manifests would be diffed against one of their parents. In that world it might make more sense to have a stateless exporter that diffed each commit against its generaldelta parent and calculated dirty trees based on that instead. However, more experiments need to be done to see what export scheme is best. For a repo with around 50,000 files, this brings down an incremental 'hg gexport' of one commit from 18 seconds with a hot file cache (and tens of minutes with a cold one) to around 2 seconds with a hot file cache.
-
Siddharth Agarwal authored
This will make our life easier in an upcoming patch.
-
Siddharth Agarwal authored
Upcoming patches will start incrementally exporting from a particular commit instead of from null. This function will be used for that..
-
- Mar 05, 2014
-
-
Siddharth Agarwal authored
The usage of getattr was unsafe. Use hgutil.safehasattr instead. util.safehasattr has been around since Mercurial 2.0. This also fixes the formerly disabled test in test-pull.t.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
Previously we'd attempt to import every single reachable commit in the Git object store. The test adds another branch to the Git repo and doesn't import it until much later. Previously we'd import it when we ran `hg -R hgrepo pull -r beta`. Now we won't.
-
Siddharth Agarwal authored
The return value as implemented in git_handler.fetch was pretty bogus. It used to return the number of values that changed in the 'refs/heads/' namespace, regardless of whether multiple values in there point to the same Mercurial commit, or whether particular heads were even imported. Fix all of that by using the actual heads in the changelog, just like vanilla Mercurial. The test output changes demonstrate examples where the code was buggy.
-
Siddharth Agarwal authored
This will be used in an upcoming patch.
-
- Mar 04, 2014
-
-
Siddharth Agarwal authored
Since Mercurial is commit-oriented, the 'no changes found' message really should rely on what new commits are in the repo, not on new heads. This also makes an upcoming patch much simpler. Since everything around this code is completely broken anyway, writing a test for this that doesn't trigger other bugs is close to impossible. An upcoming patch will include tests. The test output change is for an empty clone -- the output is precisely how vanilla Mercurial treats an empty clone.
-
Siddharth Agarwal authored
Still more bugs to fix.
-
Siddharth Agarwal authored
Same reasoning as previous patch, and same reason why this patch doesn't include a test.
-
Siddharth Agarwal authored
The theme of this and upcoming patches is that relying on self.git.object_store to figure out which commits/tags/bookmarks to import is not great. This breaks if the git repo is manually put in place (as might be done in a server-based replication scenario), or if a partial fetch pulled too many commits in for whatever reason. Indeed we were just about always pulling an entire pack in, because listkeys for bookmarks currently calls fetch_pack without any filtering. (This is probably a bug and should be fixed, but this series doesn't do that.) Instead, rely on whether we actually imported the commit into Mercurial to determine whether to import the tag. This is clean, straightforward, and clearly correct. There is a whole series of bugs in this code that any test case for this would hit -- an upcoming patch will include a test for all these bugs at once.
-
Siddharth Agarwal authored
This will be used in another context in an upcoming patch.
-
Siddharth Agarwal authored
object_store.add_object doesn't check to see if the object is already in a pack, so it is still written out in that case. Do the check ourselves before calling add_object.
-
- Feb 28, 2014
-
-
Siddharth Agarwal authored
The "new-style" extsetup has been supported since at least 2009.
-
- Mar 01, 2014
-
-
durin42 authored
-
- Feb 26, 2014
-
-
Siddharth Agarwal authored
Since the Git to Mercurial conversion process is incremental, it's at risk of missing files, or recording files the wrong way, or recording the wrong commit metadata. Add a command called 'gverify' that can verify the contents of a particular Mercurial rev against the corresponding Git commit. Currently, this is limited to checking file names, flags and contents, but this can be made as robust as desired. Further additions will probably require refactoring git_handler.py a bit though. This function is pretty fast: on a Linux machine with a warm cache, verifying a repository with around 50,000 files takes just 20 seconds. There is scope for further improvement through parallelization, but conducting tree walks in parallel is non-trivial with the current worker infrastructure in Mercurial.
-
Siddharth Agarwal authored
This function is a no-op and can be removed.
-
Siddharth Agarwal authored
This allows other functions to be able to use the `git` property without needing to care about initializing it. An upcoming patch will remove the `init_if_missing` function.
-
- Feb 25, 2014
-
-
Siddharth Agarwal authored
Previously, we'd try to access commit.parents[0] and fail. Now, check for commit.parents being empty and return what Mercurial thinks is a repository root in that case.
-
Siddharth Agarwal authored
Previously we'd just test if gitrev was falsy, which it is if the rev returned is 0, even though it shouldn't be. With this patch, test against None explicitly. This unmasks another bug: see next patch for a fix and a test.
-
- Feb 24, 2014
-
-
Siddharth Agarwal authored
Since we now directly use progress on self.ui, we shouldn't pass in self.ui as the first argument. Oops.
-
Siddharth Agarwal authored
Previously we'd recompute the repo tags each time we'd consider importing a Git tag. This is O(n^2) in the number of tags and produced noticeable slowdowns in repos with large numbers of tags. To fix this, compute the tags just once. This is correct because the only case where we'd have issues is if multiple new Git tags with the same name were introduced, which can't happen because Git tags cannot share names. For a repository with over 200 tags, this causes a no-op hg pull to be sped up by around 0.5 seconds.
-
- Feb 20, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
util.progress was a shim for Mercurial < 1.4.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
This code never worked for Mercurial >= 2.0, since it neither had repo._tags nor repo.tagscache.
-
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.
-