Skip to content
Snippets Groups Projects
  1. May 29, 2015
    • Matt Harbison's avatar
      convert: support incremental conversion with hg subrepos · daf9f7ee2a5c
      Matt Harbison authored
      This was implied in issue3486, which specifically asked for subrepo support in
      lfconvert.  Now that lfconvert uses the convert extension internally when going
      to normal files, the issue is half fixed.  But now even non largefile repos
      benefit when other transformations are needed.
      
      Supporting a full subrepo tree conversion from a single command doesn't seem
      reasonable, given the number of options that can be provided, and the
      transformations that would need to occur when entering a subrepo (consider
      'filemap' paths).  Instead, this allows the user to incrementally convert each
      hg subrepo from bottom up like so:
      
        # so convert knows the dest type when it sees a non empty dest dir
        $ hg init converted
      
        $ hg convert orig/sub1 converted/sub1
        $ hg convert orig/sub2 converted/sub2
        $ hg convert orig converted
      
      This allows different options to be applied to different subrepos more readily.
      It assumes the shamap is in the default location in each converted subrepo for
      simplicity.  It also allows for a subrepo to be cloned into place, in case _it_
      doesn't need a conversion.  I was able to convert away from using
      largefiles/bfiles in several subrepos with this mechanism.
      daf9f7ee2a5c
  2. Jun 05, 2015
  3. Jun 11, 2015
  4. Oct 27, 2014
  5. Jun 10, 2015
  6. Oct 27, 2014
    • Pierre-Yves David's avatar
      revsetbenchmarks: allow running multiple variants per revset · f08ad5d17e43
      Pierre-Yves David authored
      The current benchmarks were only testing the whole iteration. This is suboptimal
      because some changes are meaningful for things like first result, minimum or
      sorting.
      
      We introduce a "variants" feature that let you systematically add some variants
      to all revsets tested.
      
      A typical variants value would be 'plain,min,last,sort'. When testing 'all()' it
      will also provide testing for:
      - all()
      - min(all())
      - last(all())
      - sort(sort)
      
      and output:
      
         plain         min            last           sort
      0) 0.034568      0.037857       0.000074       0.034238
      1) 0.011358  32% 0.020181  53%  0.000080 108%  0.011405  33%
      
      Using revsets (who hit the API) instead of the internal API add some overhead,
      but the overhead should be the same everywhere so it still allow comparison.
      This is is more simple to implement and allows comparison with older versions
      who do not have the same API.
      f08ad5d17e43
  7. Jun 10, 2015
  8. Jun 12, 2015
  9. Jun 11, 2015
  10. Jun 09, 2015
  11. Jun 11, 2015
    • Pierre-Yves David's avatar
      phases: really fix native phase computation · 262e6ad93885
      Pierre-Yves David authored
      For some reason (probably rebase issue, leprechaun or badly resolved .rej)
      1635579f9baf contains only half of the emailed patches and do not fix the bug.
      This patch adds the other half and enable the sweet native computation for real.
      
      As expected this provide massive speedup along the board.
      
      revset #0: not public()
         plain         first
      0) 0.011960      0.010523
      1) 0.000465   3% 0.000492   4%
      
      revset #1: (tip~1000::) - public()
         plain         first
      0) 0.025700      0.025169
      1) 0.002864  11% 0.001899   7%
      
      revset #2: not public() and branch("default")
         plain         first
      0) 0.022842      0.020863
      1) 0.011418  49% 0.010948   52%
      
      However, it has a less impact (even bad) on first result time in simple
      situation.  This comes from the overhead of building the set and filtering it.
      This is especially true on my Mercurial repository (used here) where about 1/3
      of the changesets are non public and hidden. This could be mitigated by a
      caching of the set and a better usage of smartset in '_notpublic'. (But this
      won't happen in this patch because the win is massive everywhere else).
      
      revset #0: not public()
         last
      0) 0.000081
      1) 0.000493 x6.1 <-- bad impact
      
      revset #1: (tip~1000::) - public()
         last
      0) 0.013966
      1) 0.002737  19%
      
      revset #2: not public() and branch("default")
         last
      0) 0.011021
      1) 0.011038
      
      The effect mostly disappear when the number of non-public changesets is small
      and/or the repo get bigger. Result for Mozilla central:
      
      Mozilla
      
      revset #0: not public()
         plain         first         last
      0) 0.092787      0.084094      0.000080
      1) 0.000054   0% 0.000083   0% 0.000083
      
      revset #1: (tip~1000::) - public()
         plain         first         last
      0) 0.215607      0.183996      0.124962
      1) 0.031620  14% 0.006616   3% 0.031168  24%
      
      revset #2: not public() and branch("default")
         plain         first         last
      0) 0.092626      0.082687      0.000162
      1) 0.000139   0% 0.000165   0% 0.000167
      262e6ad93885
  12. Jun 12, 2015
    • Anton Shestakov's avatar
      hgweb: don't point file links at tip hash where it doesn't make sense · 32f76eccbced
      Anton Shestakov authored
      Some pages, e.g. bookmarks, help and summary don't have a meaningful revision
      context: they always either show information about tip or about the whole repo
      (and not about any specific changeset). And error pages can just show hgweb
      error messages, not related to any repo or changeset.
      
      Having a hash in the links worked (even when '{node|short}' resolved to an
      empty string on error pages), but seeing pages without revision context provide
      links with hashes is a bit confusing (unless you keep current tip hash in your
      head at all times) and not consistent with other template styles and other
      links on the same page: they don't have a hash.
      
      Let's just link to '/file', which is equal to '/file/tip'.
      32f76eccbced
    • Anton Shestakov's avatar
      hgweb: don't point graph links at tip hash where it doesn't make sense · bcc02516f384
      Anton Shestakov authored
      Some pages, e.g. bookmarks, help and summary don't have a meaningful revision
      context: they always either show information about tip or about the whole repo
      (and not about any specific changeset). And error pages can just show hgweb
      error messages, not related to any repo or changeset.
      
      When monoblue style was added in 91b0ada2d94b, however, all graph links had
      tried to point at some hash, and on such pages as described above it didn't
      make sense. On error pages '{node|short}' is empty string anyway.
      
      Of course, it worked, but seeing such pages without revision context provide
      links with hashes is a bit confusing (unless you keep current tip hash in your
      head at all times) and wasn't consistent with other template styles, other
      pages in monoblue and even other links on the same page.
      
      Let's just link to '/graph', which is equal to '/graph/tip'.
      bcc02516f384
    • Anton Shestakov's avatar
      hgweb: put help link in paper/search.tmpl separately for consistency · e0c09398c237
      Anton Shestakov authored
      Just a cosmetic markup change, no .css changes required.
      e0c09398c237
  13. Jun 11, 2015
  14. Jun 08, 2015
  15. Jun 10, 2015
  16. Jun 08, 2015
Loading