- May 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This code was quite hard to read.
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Aug 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This is handled by testutil these days; having it in each test is pointless clutter.
-
Dan Villiom Podlaski Christiansen authored
We currently imply a default path when pushing to unknown Git remotes, and add corresponding git-remote tags. Only one of our tests relies on this. To document the differences, run it with and without a path.
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This makes it easier to see what's going on.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
(it does not)
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is a premature optimisation, since Dulwich does a lot caching internally anyway. I have been unable to demonstrate any benefit from this; a bit of profiling shows that this stage of an incoming command takes ~12 seconds, even with more than 100k commits. Generally speaking, the actual conversion will take significantly longer time than caching these objects. In fact, the cache might actually be harmful for very long-running conversions, as they tend to run into memory constraints.
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Dulwich has the add_thin_pack() function for adding a pack to the repository which may be thin, i.e. refer to objects outside the pack. We can avoid that on an initial clone, however, as we know that we just created the Git repository, meaning that the pack is never thin. The overhead is negligible on smaller repositories, but can be comparable to network transfer on a fast connection. The only downside is that it just might break something if the user specifies a preexisting Git repository in the configuration, but that seems a bit esoteric.
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, we'd just load fetched data into memory, but that seems a bit wasteful. After all, some repositories can be quite large. Use a spooled temporary file instead when fetching repositories, and allow the customising the buffer size.
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This allows us to check progress more thoroughly.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Sep 08, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Mercurial core changed and simplified the batchable API in c424ff4807e6, breaking our base peer. This abstracts the batchable functionality into a method in `compat.py`, and simplifies the code in `gitrepo.py` a bit, removing a class that's now mostly redundant. https://phab.mercurial-scm.org/D11212
-
- Aug 27, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, Dulwich would make object files writable, which is inconsistent with Git; this test implicitly relied on that bug.
-
- Jul 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 27, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
pip install --pre mercurial~=5.9.0 doesn't work as expected, so we extract the versions using the PyPI API.
-
Dan Villiom Podlaski Christiansen authored
The mercurial-scm.org is somewhat unreliable, and only includes published changes. We want to notice breakage as soon as possible.
-
Dan Villiom Podlaski Christiansen authored
currently, the various branches use the same container images, meaning that we have to keep them compatible (hopefully, this doesn't break building tags)
-
- Jul 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Mercurial 5.8 and earlier would delete such a directory on errors, and the test accidentally relied on that behaviour. To work around that, we clone into the _current_ directory, which Mercurial never deletes. The test now reveals the incorrect behaviour, but the current design makes that difficult to address without tracking unnecessary state.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, users would have to set this manually to make long running conversions safely resumable. Now that we disregard it for clone, we should make our defaults safer for pull. The value of 1000 is essentially a compromise, as it isn't so small that it makes converting repositories with more commits than files slow, and not so large that it becomes infrequent with large and slow commits.
-
Dan Villiom Podlaski Christiansen authored
Given that Mercurial will delete the repository on any error, using anything more than a single transaction is a waste of resources. In fact, the only way to “recover” a partial clone using hg-git is to forcibly KILL the process. This makes us match the behaviour of Mercurial: clone isn't resumable, period, and not even inspecting the repository during the clone suggests otherwise. This currently doesn't affect the current defaults, though, which are to always use a single transaction.
-
Dan Villiom Podlaski Christiansen authored
Now that we always save the map at the end of a transaction, the previous logic for a final save is redundant.
-