- 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
-
- 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.
-
Dan Villiom Podlaski Christiansen authored
By using a transaction, we can avoid unnecessary I/O and let Mercurial do whatever it does to keep things fast. This is a significant optimisation, as cloning Dulwich from Github goes from ~1m40s to ~52s on a Mac, and ~49s to ~32s on Linux.
-
- Jun 02, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The Git metadata files are located directly within '.hg' in the store repository. To use the vfs directly, we have to lock the working directory. The Mercurial push and pull commands — reasonably — don't do that, so without this change, we cannot save or load the map during them. Ideally, we'd move these files into the store, but that's too invasive, and would break backward compatibility rather significantly, unless we add some form of upgrade/downgrade support. Instead, we simply add them to the list of files that don't need the lock.
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
When the map save frequency is set, we would previously save it the very start of the pull. That doesn't make much sense, so we switch it one commit later to avoid the unnecessary I/O.
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
When the map save frequency is set, we would previously save it the very start of the push. That doesn't make much sense, so we switch it one commit later to avoid the unnecessary I/O.
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
for extra debuggability, log where we're saving it to as well
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This avoids cluttering the tests data with infrastructure files, and adjust the name to be consistent with Mercurial's naming conventions.
-
- Jun 22, 2021
-
-
Pierre-Yves David authored
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
The default for `hggit.use-phases` is to publish the remote HEAD and tags. We want to do this on push as well, so that pushing to e.g. `master` _immediately_ publishes the relevant changesets. However, we run into the fact that we don't actually know or store the remote HEAD anywhere, so we have to do an extra round-trip to obtain it.
-
Dan Villiom Podlaski Christiansen authored
Tags normally point to fixed commits, and the Git documentation[1] is quite explicit that you shouldn't move them around willy-nilly. In other words, they rather neatly correspond to Mercurial's public phase, hence a sensible default is to always publish them, along with head. [1] https://git-scm.com/docs/git-tag#_discussion
-
Dan Villiom Podlaski Christiansen authored
-
- May 12, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This essentially makes our behaviour match the documentation, which states that ``git.public`` refers to “a list of Git branches”. It didn't: it actually referred to a list of Mercurial changesets that we would publish on push. Previously, this would lead to a rather nonsensical situation: * The remote ``stable`` points to commit A * The local, corresponding ``stable`` bookmark points to commit B * ``git.public`` is configured to list ``stable`` * The user performs a pull. Whatever you'd expect to happen in that case, it mostly likely _wouldn't_ be for B to be published, which was what happened. Please note that this change breaks backwards compatibility; previously, having ``git.public`` point to e.g. ``default/master`` would cause that to be published. But that was always undocumented.
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This makes clear what we expect to change, and also ensures that we test the behaviour with tags.
-
- Jun 11, 2020
-
-
Aay Jay Chan authored
Added tests that show the current effects of git.public and hggit.usephases.
-
- Jun 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
The method moved to stringutil, so lets add some compat layer for it.
-
Pierre-Yves David authored
-
- Jun 17, 2021
-
-
Pierre-Yves David authored
We will need it to test the obsolescence inference.
-
Pierre-Yves David authored
This give more options to the test of the code.
-
- Jun 16, 2021
-
-
Pierre-Yves David authored
We will needs that logic for obsolescence inference, so we extract it first.
-