Skip to content
Snippets Groups Projects
  1. Jun 20, 2017
  2. May 02, 2017
    • Pierre-Yves David's avatar
      caches: stop warming the cache after changegroup application · 24f55686a63d
      Pierre-Yves David authored
      Now that we garantee that branchmap cache is updated at the end of the
      transaction we can drop this update. This removes a problematic case with
      nested transaction where the new cache could be written on disk before the
      transaction is finished (and even roll-backed)
      
      Such premature cache write was visible in the following test:
      
      * tests/test-acl.t
      * tests/test-rebase-conflicts.t
      
      In addition, running the cache update later means having more date about the
      state of the repository (in particular: phases). So we can generate caches with
      more information. This creates harmless changes to the following tests:
      
      * tests/test-hardlinks-whitelisted.t
      * tests/test-hardlinks.t
      * tests/test-phases.t
      * tests/test-tags.t
      * tests/test-inherit-mode.t
      24f55686a63d
  3. May 11, 2016
  4. Nov 18, 2015
    • Laurent Charignon's avatar
      localrepo: put bookmark move following commit in one transaction · 4414d500604f
      Laurent Charignon authored
      Before this patch, making a commit on a local repo could move a bookmark and
      both operations would not be grouped as one transaction. This patch makes both
      operations part of one transaction. This is necessary to switch to the new api
      to save bookmarks repo._bookmarks.recordchange if we don't want to change the
      current behavior of rollback.
      
      Dirstate change happening after the commit is done is now part of the
      transaction mentioned above. This leads to a change in the expected output of
      several tests.
      
      The change to test-fncache happens because both lock are now released in the
      same finally clause. The lock release is made explicitly buggy in this test.
      Previously releasing lock would crash triggering release of wlock that crashes
      too. Now lock release crash does not directly result in the release of wlock.
      Instead wlock is released at garbage collection time and the error raised at
      that time "confuses" python.
      4414d500604f
  5. 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
  6. Jan 07, 2015
    • Mads Kiilerich's avatar
      branchmap: use revbranchcache when updating branch map · 7d63398fbfd1
      Mads Kiilerich authored
      The revbranchcache is read on demand before it will be used for updating the
      branch map. It is written back when the branchmap is written and it will thus
      use the same locking as branchmap. The revbranchcache instance is short-lived;
      it is only stored in the branchmap from .update() is invoked and until .write()
      is invoked. Branchmap already assume that the repo is locked in that case.
      
      The use of revbranchcache for branch map updates will make sure that the
      revbranchcache "always" is kept up-to-date.
      
      The perfbranchmap benchmark is somewhat bogus, especially when we can see that
      the caching makes a significant difference between the realistic case of a
      first run and the rare case of rerunning it with a full cache. Here are some
      'base' numbers on mozilla-central:
      Before:
      ! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3)
      After - initial, cache is empty:
      ! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3)
      After - cache is full:
      ! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4)
      
      The overhead when running with empty cache comes from checking, missing and
      updating it every time.
      
      Most of the performance improvement comes from not having to extract the branch
      info from the changelog. The last doubling of performance comes from no longer
      having to convert all branch names to local encoding but reuse the few already
      converted branch names.
      
      On the hg repo:
      Before:
      ! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
      After:
      ! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)
      7d63398fbfd1
  7. Aug 07, 2014
    • Pierre-Yves David's avatar
      phase: attach phase to the transaction instead of the lock · 37f46575d9c2
      Pierre-Yves David authored
      The phase cache file is no longer written on lock release, it is now handled by
      the transaction (as changesets and obsolescence markers are).
      
      (Hooray)
      
      As we stop relying on the lock to write phase, repos with no existing phase
      information will need to wait for a phase move or a strip to happen in order to
      get the first write in the `phaseroots` file. This explain the change in
      test-inherit-mode.t.
      
      This should not have any side effects but in very obscure cases where
      people interact with pre-2.1 and post-2.1 versions of Mercurial on the
      same repo while having MQ patches applied but the MQ extension
      disabled from time to time. A case unlikely enough to not be worth
      preserving the old behavior with awful hacks.
      37f46575d9c2
  8. Aug 06, 2014
  9. Sep 16, 2013
  10. Jan 13, 2013
    • Kevin Bullock's avatar
      filtering: rename filters to their antonyms · f3b21beb9802
      Kevin Bullock authored
      Now that changelog filtering is in place, it's become evident that
      naming the filters according to the set of revs _not_ included in the
      filtered changelog is confusing. This is especially evident in the
      collaborative branch cache scheme.
      
      This changes the names of the filters to reflect the revs that _are_
      included:
      
        hidden -> visible
        unserved -> served
        mutable -> immutable
        impactable -> base
      
      repoview.filteredrevs is renamed to filterrevs, so that callers read a
      bit more sensibly, e.g.:
      
        filterrevs('visible') # filter revs according to what's visible
      f3b21beb9802
  11. Jan 02, 2013
    • Pierre-Yves David's avatar
      clfilter: add impactable filter · 58ca19edc043
      Pierre-Yves David authored
      The `mutable` filter still have some chance to get invalidated. This will happen
      when:
      
      - you garbage collect hidden changeset,
      - public phase is moved backward,
      - something is changed in the filtering (this could be fixed)
      
      So we introduce an even more stable filtering set: everything with a revision
      number egal or higher than the first mutable changeset is filtered.
      
      The only official use of this filter is for branchcache.
      58ca19edc043
    • Pierre-Yves David's avatar
      clfilter: add mutable filtering · aff706b3a21c
      Pierre-Yves David authored
      It filters all mutable changesets, leaving only public changeset unfiltered.
      This filtering set is expected to be much more stable that the previous one as
      public changeset are unlikely to disapear.
      
      The only official use of this filter is for branchcache.
      aff706b3a21c
  12. Jan 07, 2013
    • Pierre-Yves David's avatar
      branchmap: allow to use cache of subset · a55b06885cda
      Pierre-Yves David authored
      Filtered repository are *subset* of unfiltered repository. This means that a
      filtered branchmap could be use to compute the unfiltered version.
      
      And filtered version happen to be subset of each other:
      - "all() - unserved()" is a subset of "all() - hidden()"
      - "all() - hidden()" is a subset of "all()"
      
      This means that branchmap with "unfiltered" filter can be used as a base for
      "hidden" branchmap that itself could be used as a base for unfiltered
      branchmap.
      
         unserved < hidden < None
      
      This changeset implements this mechanism. If the on disk branchcache is not valid
      we use the branchcache of the nearest subset as base instead of computing it from
      scratch. Such fallback can be cascaded multiple time is necessary.
      
      Note that both "hidden" and "unserved" set are a bit volatile. We will add more
      stable filtering in next changesets.
      
      This changeset enables collaboration between no filtering and "unserved"
      filtering. Fixing performance regression introduced by 47f00b0de337
      a55b06885cda
  13. Jun 10, 2012
  14. Mar 01, 2012
    • Javi Merino's avatar
      tests: ignore the return code of chmod in test-inherit-mode · 7cf8de5a82d8
      Javi Merino authored
      In freebsd, a newly created directory has the same group as the parent
      directory by default.  That means that the test directory created by
      test-inherit-mode.t is owned by root's group, so "chmod g+s .hg/store"
      fails to set the SGID bit and returns 1.  If we ignore chmod's return
      code, the testsuite passes again.
      7cf8de5a82d8
  15. Jan 30, 2012
  16. Jan 13, 2012
  17. Nov 10, 2011
  18. Nov 07, 2011
  19. May 01, 2011
    • Alexander Solovyov's avatar
      fix bookmarks rollback behavior · 89e7d35e0ef0
      Alexander Solovyov authored
      Before this patch undo.bookmarks was created on bookmarks write and
      not with other transaction-related files. There were two issues: first
      is that if you have changed bookmarks few times after a transaction
      happened, rollback will give you a state which can point to
      non-existing revision. Second is that if you have not changed
      bookmarks after a transaction, rollback will touch your state anyway.
      
      This change also adds `localrepo._writejournal` method, which can be
      used by other extensions to save their transaction-related backup in
      right time.
      89e7d35e0ef0
  20. Jan 04, 2011
    • jfh's avatar
      move tags.cache and branchheads.cache to a collected cache folder .hg/cache/ · 5ccdca7df211
      jfh authored
      The generation of cache files like tags.cache and branchheads.cache is not an
      actual reflection of things changing in the whole of the .hg directory (like eg
      a commit or a rebase or something) but instead these cache files are just part
      of bookkeeping. As such its convienant to allow various clients to ignore file
      events to do with these cache files which would otherwise cause a double
      refresh. Eg one refresh might occur after a commit, but the act of refreshing
      after the commit would cause Mercurial to generate a new branchheads.cache which
      would then cause a second refresh, for clients.
      
      However if these cache files are moved into a directory like eg .hg/cache/ then
      GUI clients on OSX (and possibly other platforms) can happily ignore file events
      in this cache directory.
      5ccdca7df211
  21. Oct 16, 2010
  22. Aug 30, 2010
  23. Mar 18, 2008
  24. Feb 21, 2008
  25. Feb 15, 2008
  26. Feb 10, 2008
  27. Feb 09, 2008
Loading