Skip to content
Snippets Groups Projects
  1. Jun 24, 2021
  2. Jun 18, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      incoming: stop caching dulwich objects · a28216b2
      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.
      a28216b2
  3. Jul 07, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      clone: move in pack when possible · 4dc1e9ba
      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.
      4dc1e9ba
    • Dan Villiom Podlaski Christiansen's avatar
  4. Jun 21, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      import: use spooled temporary file · 4aa0e095
      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.
      4aa0e095
    • Dan Villiom Podlaski Christiansen's avatar
      clone: always use a single transaction · bf9084d8
      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.
      bf9084d8
    • Dan Villiom Podlaski Christiansen's avatar
      pull: remove redundant map save · 1fddab90
      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.
      1fddab90
    • Dan Villiom Podlaski Christiansen's avatar
      pull: use a transaction between map saves · 6bc30f99
      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.
      6bc30f99
  5. Jun 02, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      hgrepo: don't require wlock for writing git metadata · 744f9d32
      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.
      744f9d32
  6. Jun 21, 2021
  7. Jun 18, 2021
  8. Jun 21, 2021
  9. Jun 18, 2021
  10. May 12, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      phases: avoid accidentally marking a divergent bookmark as public · 4fb7c538
      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.
      4fb7c538
  11. Jun 17, 2021
  12. Jun 16, 2021
  13. Jun 15, 2021
  14. Jun 16, 2021
  15. Jun 18, 2021
  16. May 08, 2021
  17. Jun 02, 2021
  18. Jun 01, 2021
  19. May 31, 2021
  20. Sep 15, 2020
  21. Jun 01, 2021
  22. May 28, 2021
  23. May 21, 2021
  24. May 13, 2021
  25. May 10, 2021
  26. May 12, 2021
  27. May 05, 2021
  28. Dec 26, 2020
    • Dan Villiom Podlaski Christiansen's avatar
      push & pull: consolidate invalid path handling, default to skipping · b46639f3
      Dan Villiom Podlaski Christiansen authored
      The current behaviour is quite unhelpful, given that it either allows
      you to abort the conversion or generate a bogus repository. As an
      example, GitHub rejects anything with a `.git` in it.
      
      Instead, the new default is to issue a warning and simply discard the
      dangerous files. Although this might cause problems down the line, I'd
      much rather have those problems than just have hg-git give up.
      
      As an example of such a bogus repository, look no further than this
      one. c43c02cc803a committed some tests from Dulwich with nested Git
      repositories, and a061dce264b7 renamed them. Prior to this change,
      hg-git could not push its own repository to GitHub.
      
      Further more, Mercurial disallows paths containing carriage return
      (CR) and newline (NL) characters; as noted in the original Mercurial
      bug report that enabled this behaviour,[1] such paths appear for
      folder icons on macOS. This was reported on the list by Uwe Brauer.[2]
      
      Since Mercurial simply cannot store these files, we always either skip
      them or abort the conversion.
      
      [1] https://bz.mercurial-scm.org/show_bug.cgi?id=352
      [2] https://groups.google.com/g/hg-git/c/Rz3oRzrMS3Q/m/RRq4AIMsBAAJ
      b46639f3
  29. Feb 22, 2021
Loading