Skip to content
Snippets Groups Projects
  1. May 31, 2021
  2. Jul 06, 2021
  3. Feb 05, 2021
  4. Jun 24, 2021
  5. Jul 31, 2021
  6. Aug 01, 2021
  7. Jul 06, 2021
  8. Feb 05, 2021
  9. Jul 06, 2021
  10. Jun 24, 2021
  11. Jun 18, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      incoming: stop caching dulwich objects · a28216b2ea69
      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.
      a28216b2ea69
  12. Jul 07, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      clone: move in pack when possible · 4dc1e9ba165b
      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.
      4dc1e9ba165b
    • Dan Villiom Podlaski Christiansen's avatar
      9a6491edea3e
  13. Jun 21, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      import: use spooled temporary file · 4aa0e09581a9
      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.
      4aa0e09581a9
  14. Jul 09, 2021
  15. Jul 07, 2021
  16. Oct 23, 2021
  17. Sep 08, 2021
  18. Aug 27, 2021
  19. Jul 31, 2021
  20. Jul 07, 2021
  21. Jul 27, 2021
  22. Jul 02, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      tests: don't rely on cloning into an empty directory · c3a6d1e748b5
      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.
      c3a6d1e748b5
  23. Jul 06, 2021
  24. Jun 21, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      pull: adjust default map save interval to 1000 · a81137caad95
      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.
      a81137caad95
    • Dan Villiom Podlaski Christiansen's avatar
      clone: always use a single transaction · bf9084d8d832
      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.
      bf9084d8d832
    • Dan Villiom Podlaski Christiansen's avatar
      pull: remove redundant map save · 1fddab909c2b
      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.
      1fddab909c2b
Loading