Skip to content
Snippets Groups Projects
  1. Apr 01, 2015
  2. Mar 31, 2015
    • Wagner Bruna's avatar
      i18n-pt_BR: synchronized with d09262d6ec23 · 2e2e9a0750f9
      Wagner Bruna authored
      3.3.3
      2e2e9a0750f9
    • Matt Harbison's avatar
      forget: cleanup the output for an inexact case match on icasefs · c780a63f61ca
      Matt Harbison authored
      Previously, specifying a file name but not matching the dirstate case yielded
      the following, even though the file was actually removed:
      
        $ hg forget capsdir1/capsdir/abc.txt
        not removing capsdir\a.txt: file is already untracked
        removing CapsDir\A.txt
        [1]
      
      This change doesn't appear to cause any extra filesystem accesses, even if a
      nonexistant file is specified.
      
      If a directory is specified without a case match, it is (and was previously)
      still silently ignored.
      c780a63f61ca
    • Matt Harbison's avatar
      dirstate: don't require exact case when adding dirs on icasefs (issue4578) · 2bb13f2b778c
      Matt Harbison authored
      We don't require it when adding files on a case insensitive filesystem, so don't
      require it to add directories for consistency.
      
      The problem with the previous code was that _walkexplicit() was only returning
      the normalized directory.  The file(s) in the directory are then appended, and
      passed to the matcher.  But if the user asks for 'capsdir1/capsdir', the matcher
      will not accept 'CapsDir1/CapsDir/AbC.txt', and the name is dropped.  Matching
      based on the non-normalized name is required.
      
      If not normalizing, skip the extra string building for efficiency.  '.' is
      replaced with '' so that the path being tested when no file is specified, isn't
      prefixed with './' (and therefore fail the match).
      2bb13f2b778c
    • Nathan Goldbaum's avatar
      d09262d6ec23
  3. Mar 28, 2015
  4. Mar 22, 2015
  5. Mar 20, 2015
    • Pierre-Yves David's avatar
      mergecopies: reuse ancestry context when traversing file history (issue4537) · 9372180b8c9b
      Pierre-Yves David authored
      Merge copies is traversing file history in search for copies and renames.
      Since 3.3 we are doing "linkrev adjustment" to ensure duplicated filelog entry
      does not confuse the traversal. This "linkrev adjustment" involved ancestry
      testing and walking in the changeset graph. If we do such walk in the changesets
      graph for each file, we end up with a 'O(<changesets>x<files>)' complexity
      that create massive issue. For examples, grafting a changeset in Mozilla's repo
      moved from 6 seconds to more than 3 minutes.
      
      There is a mechanism to reuse such ancestors computation between all files. But
      it has to be manually set up in situation were it make sense to take such
      shortcut. This changesets set this mechanism up and bring back the graph time
      from 3 minutes to 8 seconds.
      
      To do so, we need a bigger control on the way 'filectx' are instantiated during
      each 'checkcopies' calls that 'mergecopies' is doing. We add a new 'setupctx'
      that configure and return a 'filectx' factory. The function make sure the
      ancestry context is properly created and the factory make sure it is properly
      installed on returned 'filectx'.
      9372180b8c9b
    • Pierre-Yves David's avatar
      adjustlinkrev: handle 'None' value as source · 5a12ef618c03
      Pierre-Yves David authored
      When the source rev value is 'None', the ctx is a working context. We
      cannot compute the ancestors from there so we directly skip to its
      parents. This will be necessary to allow 'None' value for
      '_descendantrev' itself necessary to make all contexts used in
      'mergecopies' reuse the same '_ancestrycontext'.
      5a12ef618c03
    • Pierre-Yves David's avatar
      adjustlinkrev: prepare source revs for ancestry only once · 86de531e07e1
      Pierre-Yves David authored
      We'll need some more complex initialisation to handle workingfilectx
      case. We do this small change in a different patch for clarity.
      86de531e07e1
    • Pierre-Yves David's avatar
      annotate: reuse ancestry context when adjusting linkrev (issue4532) · dd01834a696f
      Pierre-Yves David authored
      The linkrev adjustment will likely do the same ancestry walking multiple time
      so we already have an optional mechanism to take advantage of this. Since
      2896f53509a7, linkrev adjustment was done lazily to prevent too bad performance
      impact on rename computation. However, this laziness created a quadratic
      situation in 'annotate'.
      
      Mercurial repo: hg annotate mercurial/commands.py
      before:   8.090
      after:  36.300
      
      Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp
      before:   1.190
      after:  290.230
      
      
      So we setup sharing of the ancestry context in the annotate case too. Linkrev
      adjustment still have an impact but it a much more sensible one.
      
      Mercurial repo: hg annotate mercurial/commands.py
      before:  36.300
      after:   10.230
      
      Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp
      before: 290.230
      after:    5.560
      dd01834a696f
  6. Mar 14, 2015
  7. Mar 13, 2015
  8. Mar 05, 2015
  9. Mar 04, 2015
  10. Mar 02, 2015
  11. Feb 06, 2015
    • Mads Kiilerich's avatar
      revisionbranchcache: fall back to slow path if starting readonly (issue4531) · 5b4ed033390b
      Mads Kiilerich authored
      Transitioning to Mercurial versions with revision branch cache could be slow as
      long as all operations were readonly (revset queries) and the cache would be
      populated but not written back.
      
      Instead, fall back to using the consistently slow path when readonly and the
      cache doesn't exist yet. That avoids the overhead of populating the cache
      without writing it back.
      
      If not readonly, it will still populate all missing entries initially. That
      avoids repeated writing of the cache file with small updates, and it also makes
      sure a fully populated cache available for the readonly operations.
      3.3.1
      5b4ed033390b
  12. Feb 25, 2015
    • Katsunori FUJIWARA's avatar
      largefiles: access to specific fields only if largefiles enabled (issue4547) · d414c28db84d
      Katsunori FUJIWARA authored
      Even if largefiles extension is enabled in a repository, "repo"
      object, which isn't "largefiles.reposetup()"-ed, is passed to
      overridden functions in the cases below unexpectedly, because
      extensions are enabled for each repositories strictly.
      
        (1) clone without -U:
        (2) pull with -U:
        (3) pull with --rebase:
      
          combination of "enabled@src", "disabled@dst" and
          "not-required@src" cause this situation.
      
             largefiles     requirement
          @src     @dst     @src            result
          -------- -------- --------------- --------------------
          enabled  disabled not-required    aborted unexpectedly
                            required        requirement error (intentional)
          -------- -------- --------------- --------------------
          enabled  enabled  *               success
          -------- -------- --------------- --------------------
          disabled enabled  *               success (only for "pull")
          -------- -------- --------------- --------------------
          disabled disabled not-required    success
                            required        requirement error (intentional)
          -------- -------- --------------- --------------------
      
        (4) update/revert with a subrepo disabling largefiles
      
      In these cases, overridden functions cause accessing to largefiles
      specific fields of not "largefiles.reposetup()"-ed "repo" object, and
      execution is aborted.
      
        - (1), (2), (4) cause accessing to "_lfstatuswriters" in
          "getstatuswriter()" invoked via "updatelfiles()"
      
        - (3) causes accessing to "_lfcommithooks" in "overriderebase()"
      
      For safe accessing to these fields, this patch examines whether passed
      "repo" object is "largefiles.reposetup()"-ed or not before accessing
      to them.
      
      This patch chooses examining existence of newly introduced
      "_largefilesenabled" instead of "_lfcommithooks" and
      "_lfstatuswriters" directly, because the former is better name for the
      generic "largefiles is enabled in this repo" mark than the latter.
      
      In the future, all other overridden functions should avoid largefiles
      specific processing for efficiency, and "_largefilesenabled" is better
      also for such purpose.
      
      BTW, "lfstatus" can't be used for such purpose, because some code
      paths set it forcibly regardless of existence of it in specified
      "repo" object.
      d414c28db84d
  13. Feb 18, 2015
  14. Mar 02, 2015
  15. Feb 26, 2015
  16. Feb 05, 2015
    • Katsunori FUJIWARA's avatar
      revset: mask specific names for named() predicate · 38824c53c2f1
      Katsunori FUJIWARA authored
      Before this patch, revset predicate "tag()" and "named('tags')" differ
      from each other, because the former doesn't include "tip" but the
      latter does.
      
      For equivalence, "named('tags')" shouldn't include the revision
      corresponded to "tip". But just removing "tip" from the "tags"
      namespace causes breaking backward compatibility, even though "tip"
      itself is planned to be eliminated, as mentioned below.
      
          http://selenic.com/pipermail/mercurial-devel/2015-February/066157.html
      
      To mask specific names ("tip" in this case) for "named()" predicate,
      this patch introduces "deprecated" into "namespaces", and makes
      "named()" predicate examine whether each names are masked by the
      namespace, to which they belong.
      
      "named()" will really work correctly after 3.3.1 (see 873eb5db89c8 for
      detail), and fixing this on STABLE before 3.3.1 can prevent initial
      users of "named()" from expecting "named('tags')" to include "tip".
      
      It is reason why this patch is posted for STABLE, even though problem
      itself isn't so serious.
      
      This may have to be flagged as "(BC)", if applied on DEFAULT.
      38824c53c2f1
  17. Mar 01, 2015
  18. Feb 28, 2015
  19. Feb 18, 2015
    • Martin von Zweigbergk's avatar
      subrepo: add tests for change/remove conflicts · 756c5c8331b0
      Martin von Zweigbergk authored
      There are currently no tests for change/remove conflicts of subrepos,
      and it's pretty broken. Add some tests demonstrating some of the
      breakages and fix the most obvious one (a KeyError when trying to look
      up a subrepo in the wrong context).
      756c5c8331b0
  20. Feb 12, 2015
    • Anton Shestakov's avatar
      hgweb: recreate old DOM structure for css in monoblue style · 31bedb15e2e5
      Anton Shestakov authored
      There's a "p.changeset-age span" css block in style-monoblue.css with quite a
      bit of rules, including position. They were all unused, since there weren't
      matching span element inside the p.changeset-age.
      
      The span was removed in b24e5a708fad (as it seemed meaningless at the time?)
      and since then relative changeset age text looked weird and broken.
      
      "age" class is used for calculating relative changeset age in javascript: all
      content of such element is replaced with human-friendly text (e.g.
      "yesterday"). So the new span gets the age class.
      31bedb15e2e5
  21. Feb 11, 2015
  22. Feb 02, 2015
  23. Feb 03, 2015
    • Katsunori FUJIWARA's avatar
      revset: get revision number of each node from target namespaces · 873eb5db89c8
      Katsunori FUJIWARA authored
      Before this patch, revset predicate "named()" uses each nodes gotten
      from target namespaces directly.
      
      This causes problems below:
      
        - combination of other predicates doesn't work correctly, because
          they assume that revisions are listed up in number
      
        - "hg log" doesn't show any revisions for "named()" result, because:
      
          - "changeset_printer" stores formatted output for each revisions
            into dict with revision number (= ctx.rev()) as a key of them
      
          - "changeset_printer.flush(rev)" writes stored output for
            the specified revision, but
      
          - "commands.log" invokes it with the node, gotten from "named()"
      
        - "hg debugrevspec" shows nodes (= may be binary) directly
      
      Difference between revset predicate "tag()" and "named('tags')" in
      tests is fixed in subsequent patch.
      873eb5db89c8
  24. Feb 02, 2015
Loading