Skip to content
Snippets Groups Projects
  1. Jul 07, 2021
  2. Oct 23, 2021
  3. Sep 08, 2021
  4. Aug 27, 2021
  5. Jul 31, 2021
  6. Jul 07, 2021
  7. Jul 27, 2021
  8. Jul 02, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      tests: don't rely on cloning into an empty directory · c3a6d1e7
      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.
      c3a6d1e7
  9. Jul 06, 2021
  10. Jun 21, 2021
    • Dan Villiom Podlaski Christiansen's avatar
      pull: adjust default map save interval to 1000 · a81137ca
      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.
      a81137ca
    • 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
  11. 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
  12. Jun 21, 2021
  13. Jun 18, 2021
  14. Jun 21, 2021
  15. Jun 18, 2021
  16. Jun 21, 2021
  17. Jun 24, 2021
  18. Jun 22, 2021
  19. Jun 18, 2021
  20. 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
  21. Jun 18, 2021
  22. Jun 11, 2020
  23. Jun 22, 2021
  24. Jun 17, 2021
  25. Jun 16, 2021
Loading