Skip to content
Snippets Groups Projects
  1. Jan 18, 2015
  2. Jan 17, 2015
  3. Jan 16, 2015
  4. Jan 17, 2015
    • Pierre-Yves David's avatar
      transaction: include backup file in the "undo" transaction · d251da5e0e84
      Pierre-Yves David authored
      Once the transaction is closed, we now write transaction related data for
      possible future undo. For now, we only do it for full file "backup" because
      their were not handle at all in that case. In the future, we could move all the
      current logic to set undo up (that currently exists in localrepository) inside
      transaction itself, but it is not strictly requires to solve the current
      situation.
      d251da5e0e84
    • Pierre-Yves David's avatar
      transaction: pass the name of the "undo" journal to the transaction · 426607be9c69
      Pierre-Yves David authored
      It is time for the transaction to be responsible for setting up the
      undo data. It is necessary to move this logic into the transaction
      because many more files are handled now, and the transaction is the
      object tracking them all.
      
      The value can be set to None if no undo should be set.
      426607be9c69
    • Pierre-Yves David's avatar
      rollback: have an empty entry for the vfsmap in rollback · bfa52f4ecf54
      Pierre-Yves David authored
      This empty string key is used for the store. This will be needed to properly
      rollback backup in a future changesets.
      bfa52f4ecf54
  5. Jan 16, 2015
  6. Jan 05, 2015
    • Pierre-Yves David's avatar
      transaction: use 'util.copyfile' for creating backup · 5eb3541f907e
      Pierre-Yves David authored
      Using 'copyfile' (single file) instead of 'copyfiles' (tree) will ensures
      destination file will be overwritten. This will prevent some abort if backup
      file are left in place for random reason.
      
      It also seems more correct.
      5eb3541f907e
    • Pierre-Yves David's avatar
      copyfile: allow optional hardlinking · 4e451d1359de
      Pierre-Yves David authored
      Some code paths use 'copyfiles' (full tree) for a single file to take advantage
      of the best-effort-hard-linking parameter. We add similar parameter and logic
      to 'copyfile' (single file) for this purpose.
      
      The single file version have the advantage to overwrite the destination file if
      it exists.
      4e451d1359de
  7. Jan 16, 2015
    • Eric Sumner's avatar
      repair: add experimental option to write bundle2 files · b21c2e0ee8a3
      Eric Sumner authored
      This adds an experimental option 'strip-bundle2-version' which causes backup
      bundles to use bundle2 formatting.  Especially for generaldelta repositories,
      this should provide significant performance gains for any operation that needs
      to write a backup.
      b21c2e0ee8a3
  8. Jan 15, 2015
  9. Jan 17, 2015
  10. Jan 09, 2015
    • Mads Kiilerich's avatar
      largefiles: don't rehash largefiles in updatelfiles if standin hash changed · f21a0d6d6efd
      Mads Kiilerich authored
      Standins are read before and after an update/merge, and all the standins that
      changes are handed to updatelfiles for getting their corresponding largefiles
      updated. updatelfiles would then hash the largefile and see if it already
      matched the new expected hash. If so, it would skip the update. If different,
      the largefile would be updated.
      
      It would happen very rarely that the largefile happened to match the new hash
      (and thus not the old one) and the hashing would thus be pointless ... and
      hashing is not cheap.
      
      Instead, when it is known that the standin hash changed (from an update), just
      update the standin unconditionally. If the largefile was "unsure" before the
      update, it was hashed at that point, so we know there is nothing to preserve.
      (Also, the hashing in updatelfiles was not used to preserve changes, but only
      to be lazy about updating the largefile, so nothing is lost by not doing this
      extra hashing.)
      
      There might be rare situations where we now will update largefiles that didn't
      have to be updated, but in all relevant cases (?) this will improve
      performance.
      
      Updates on a repo with some big largefiles has been seen to go from 9.19 s to
      6.8 s - that is 26% less painful.
      f21a0d6d6efd
  11. Jan 16, 2015
  12. Jan 15, 2015
  13. Jan 16, 2015
  14. Jan 15, 2015
  15. Jan 13, 2015
    • Matt Harbison's avatar
      largefiles: cleanup overrideadd() · 054cfb7c33ae
      Matt Harbison authored
      This was a remnant of the code prior to overridding cmdutil.add().
      054cfb7c33ae
    • Matt Harbison's avatar
      largefiles: enable subrepo support for add · 5ce8dcd05dc4
      Matt Harbison authored
      The --large, --normal and --lfsize args couldn't be passed to a subrepo before,
      and files in the subrepos would be added silently (if -v wasn't specified) as
      normal files.  As an added bonus, 'hg add --dry-run' no longer prints that
      largefiles would also be added as normal files as well.
      5ce8dcd05dc4
    • Matt Harbison's avatar
      add: pass options via keyword args · 9994f45ba714
      Matt Harbison authored
      The largefiles extensions needs to be able to pass --large, --normal and
      --lfsize to subrepos via cmdutil.add() and hgsubrepo.add().  Rather than add
      additional special purpose arguments, stop extracting the existing args from the
      **opts passed to commands.add() and just pass them along.
      9994f45ba714
  16. Dec 31, 2014
  17. Jan 11, 2015
    • Angel Ezquerra's avatar
      share: replace the bookmarks.shared file with an entry on a new "shared" file · 7e71898a7cdc
      Angel Ezquerra authored
      cd79fb4d75fd introduced a way to share bookmarks. When a repository share that
      shares bookmarks was created, a .hg/bookmarks.shared file was created to mark
      the repository share as one that shares its bookmarks.
      
      We have plans to introduce other levels of sharing, including a "full share"
      mode. Rather than creating a new ".shared" file for each new thing that we may
      want to share It seems better to create a single "shared" file that will list
      what is shared for a given shared repository. This should make it much easier
      to get a list of everything that is shared by a given shared repository.
      
      The shared file contains a list of shared "items" (such as bookmarks). Each
      shared "item" is added as a new line in the file. For now the only possible
      entry in the file is "bookmarks".
      7e71898a7cdc
  18. Nov 02, 2014
  19. Jan 16, 2015
Loading