1. 02 Jul, 2021 1 commit
    • 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
  2. 06 Jul, 2021 1 commit
  3. 21 Jun, 2021 4 commits
    • 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
    • Dan Villiom Podlaski Christiansen's avatar
      pull: use a transaction between map saves · 6bc30f991fc5
      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.
      6bc30f991fc5
  4. 02 Jun, 2021 1 commit
    • Dan Villiom Podlaski Christiansen's avatar
      hgrepo: don't require wlock for writing git metadata · 744f9d32a694
      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.
      744f9d32a694
  5. 21 Jun, 2021 1 commit
  6. 18 Jun, 2021 1 commit
  7. 21 Jun, 2021 1 commit
  8. 18 Jun, 2021 1 commit
  9. 21 Jun, 2021 2 commits
  10. 24 Jun, 2021 1 commit
  11. 22 Jun, 2021 1 commit
  12. 18 Jun, 2021 3 commits
  13. 31 May, 2021 1 commit
  14. 12 May, 2021 1 commit
    • Dan Villiom Podlaski Christiansen's avatar
      phases: avoid accidentally marking a divergent bookmark as public · 4fb7c538b817
      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.
      4fb7c538b817
  15. 18 Jun, 2021 1 commit
  16. 04 May, 2021 2 commits
  17. 13 Jun, 2021 1 commit
  18. 28 May, 2021 1 commit
  19. 21 May, 2021 1 commit
  20. 13 May, 2021 2 commits
  21. 12 May, 2021 2 commits
  22. 02 Feb, 2021 1 commit
  23. 28 Jan, 2021 1 commit
  24. 17 Apr, 2021 1 commit
  25. 12 May, 2021 1 commit
  26. 10 May, 2021 2 commits
  27. 09 May, 2021 1 commit
  28. 05 May, 2021 2 commits
  29. 28 Apr, 2021 1 commit