- Feb 08, 2025
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
Fixes #442
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Dec 03, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 18, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
Saw one of these in the Dulwich repository today. Unfortunately, this seems to be caused by a bug in some library, so it's not easily reproducible.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
The differences are deep into rename support, and seem unlikely to be fixed anytime soon. Just note it, for now.
-
- Aug 30, 2024
-
-
Matt Harbison authored
On Windows, I had problems both cloning and pulling new changes from the server. The workaround was the clone/pull in WSL using Linux python. Not sure when this broke, but apparently `tempfile.NamedTemporaryFile` has a lot of... limitations on Windows.[1] My suggestion of using `mercurial.util.unlink()` in the bug report didn't work for pulling changes. I didn't test if it would have worked for cloning. Note that this isn't a problem on the default branch, because support for `dulwich` prior to 0.20 drops this code. It will generate a merge conflict, but can be thrown away. [1] https://stackoverflow.com/a/49868505
-
- Nov 09, 2023
-
-
Dan Villiom Podlaski Christiansen authored
The stated purpose for this is for testing. However, it's not for testing of hg-git, but of git-remote-hg. The mode has been broken for years, though, and given that it doesn't actually rely on the known-good modes of hg-git, it doesn't offer much guarantee of anything actually working. Removing as general cruft that needlessly complicates the codebase. Closes: #281 !211
-
- Jun 07, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 25, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
* don't highlight the old homepage * mention the matrix channel
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 09, 2024
-
-
Dan Villiom Podlaski Christiansen authored
The Rust extensions has a bug in rename detection that affects hg-git. Presumably, it'll be fixed in the next release. See: https://github.com/jelmer/dulwich/issues/1325 Closes: #437
-
- Jun 07, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 06, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 01, 2024
-
-
Dan Villiom Podlaski Christiansen authored
We do this in separate threads, by default up to the core count available or four, as a sensible limit. There are two possible ways that we could pack objects: 1) Gather up the objects in-memory, and write them as a single pack. 2) Write the objects as loose, and then pack them later. We want to pack as many objects as possible into a single pack, as that yields the best compression. However, the first option has two main downsides: First of all, we have to have the objects in memory, and for long-running conversions, this could be a _lot_ of objects. Second, hg-git currently assumes that it can just look up the tree in the Git repository. Sure, we could cache that, but that's extra complexity. Instead, we go for the second option. Packing is a rather slow operation, as it involves actually compressing the objects, and Dulwich doesn't seem particularly fast at that. However, as a mostly I/O and compression bound operation, it mostly sidesteps Python's infamous Global Interpreter Lock, making it amenable to normal threading. While this is _also_ somewhat complicated, it's complexity that we can isolate into a single module, avoiding further cluttering in the already complicated code we have elsewhere. The current implementation uses worker threads that regularly check whether the export is complete. Some systems have a _lot_ of cores, and the conversion will always be bound on the single-thread actual conversion anyway. Hence, I limited the default to using just three threads for packing; packing shouldn't take more than about three times as long as exporting, but we'll see… Closes: #429
-
- Jun 06, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-