Skip to content
Snippets Groups Projects
  1. Mar 14, 2015
  2. Mar 13, 2015
  3. Mar 05, 2015
  4. Mar 04, 2015
  5. Mar 02, 2015
  6. Feb 06, 2015
    • Mads Kiilerich's avatar
      revisionbranchcache: fall back to slow path if starting readonly (issue4531) · 5b4ed033
      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.
  7. Feb 25, 2015
    • Katsunori FUJIWARA's avatar
      largefiles: access to specific fields only if largefiles enabled (issue4547) · d414c28d
      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.
      d414c28d
  8. Feb 18, 2015
  9. Mar 02, 2015
  10. Feb 26, 2015
  11. Feb 05, 2015
    • Katsunori FUJIWARA's avatar
      revset: mask specific names for named() predicate · 38824c53
      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.
      38824c53
  12. Mar 01, 2015
  13. Feb 28, 2015
  14. Feb 18, 2015
    • Martin von Zweigbergk's avatar
      subrepo: add tests for change/remove conflicts · 756c5c83
      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).
      756c5c83
  15. Feb 12, 2015
    • Anton Shestakov's avatar
      hgweb: recreate old DOM structure for css in monoblue style · 31bedb15
      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.
      31bedb15
  16. Feb 11, 2015
  17. Feb 02, 2015
  18. Feb 03, 2015
    • Katsunori FUJIWARA's avatar
      revset: get revision number of each node from target namespaces · 873eb5db
      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.
      873eb5db
  19. Feb 02, 2015
  20. Jan 31, 2015
  21. Jan 29, 2015
  22. Feb 01, 2015
  23. Jan 30, 2015
    • Pierre-Yves David's avatar
      _adjustlinkrev: reuse ancestors set during rename detection (issue4514) · c1ce5442
      Pierre-Yves David authored
      The new linkrev adjustement mechanism makes rename detection very slow, because
      each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we
      introduce a simplistic way to share the ancestors computation for the linkrev
      validation phase.
      
      We can reuse the ancestors in that case because we do not care about
      sub-branching in the ancestors graph.
      
      The cached set will be use to check if the linkrev is valid in the search
      context. This is the vast majority of the ancestors usage during copies search
      since the uncached one will only be used when linkrev is invalid, which is
      hopefully rare.
      c1ce5442
    • Pierre-Yves David's avatar
      filectx: move _adjustlinkrev to a method · 087603b5
      Pierre-Yves David authored
      We are going to introduce some wider caching mechanisms during linkrev
      adjustment. As there is no specific reason to not be a method and some
      reasons to be a method, let's make it a method.
      087603b5
    • Katsunori FUJIWARA's avatar
      revset: raise RepoLookupError to make present() predicate continue the query · eeb5d5ab
      Katsunori FUJIWARA authored
      Before this patch, "bookmark()", "named()" and "tag()" predicates
      raise "Abort", when the specified pattern doesn't match against
      existing ones.
      
      This prevents "present()" predicate from continuing the query, because
      it only catches "RepoLookupError".
      
      This patch raises "RepoLookupError" instead of "Abort", to make
      "present()" predicate continue the query, even if "bookmark()",
      "named()" or "tag()" in the sub-query of it are aborted.
      
      This patch doesn't contain raising "RepoLookupError" for "re:" pattern
      in "tag()", because "tag()" treats it differently from others. Actions
      of each predicates at failure of pattern matching can be summarized as
      below:
      
        predicate  "literal:"  "re:"
        ---------- ----------- ------------
        bookmark   abort       abort
        named      abort       abort
        tag        abort       continue (*1)
      
        branch     abort       continue (*2)
        ---------- ----------- ------------
      
      "tag()" may have to abort in the (*1) case for similarity, but this
      change may break backward compatibility of existing revset queries. It
      seems to have to be changed on "default" branch (with "BC" ?).
      
      On the other hand, (*2) seems to be reasonable, even though it breaks
      similarity, because "branch()" in this case doesn't check exact
      existence of branches, but does pick up revisions of which branch
      matches against the pattern.
      
      This patch also adds tests for "branch()" to clarify behavior around
      "present()" of similar predicates, even though this patch doesn't
      change "branch()".
      eeb5d5ab
  24. Feb 01, 2015
    • Katsunori FUJIWARA's avatar
      templatekw: re-add showtags() to list tags keyword up in online help · 0870bb93
      Katsunori FUJIWARA authored
      Changeset d69a7fc68ad5 removed "showtags()" definition for "tags"
      template keyword from "templatekw.py", because "namespaces" puts a
      helper function for it into template keyword map automatically. This
      works correctly from the point of view of templating functionality.
      
      But on the other hand, it removed "tags" template keyword from "hg
      help templates" unexpectedly, because online help text is built before
      "namespaces" puts a helper function for "tags" into template keyword
      map.
      
      This patch is a kind of backing d69a7fc68ad5 out, but this implements
      "showtags()" with newly introduced "shownames()" instead of originally
      used "showlist()".
      0870bb93
  25. Jan 31, 2015
    • Matt Harbison's avatar
      largefiles: don't interfere with logging normal files · 34493912
      Matt Harbison authored
      The previous code was adding standin files to the matcher's file list when
      neither the standin file nor the original existed in the context.  Somehow, this
      was confusing the logging code into behaving differently from when the extension
      wasn't loaded.
      
      It seems that this was an attempt to support naming a directory that only
      contains largefiles, as a test fails if the else clause is dropped entirely.
      Therefore, only append the "standin" if it is a directory.  This was found by
      running the test suite with --config extensions.largefiles=.
      
      The first added test used to log an additional cset that wasn't logged normally.
      The only relation it had to file 'a' is that 'a' was the source of a move, but
      it isn't clear why having '.hglf/a' in the list causes this change:
      
          @@ -47,6 +47,11 @@
      
           Make sure largefiles doesn't interfere with logging a regular file
             $ hg log a --config extensions.largefiles=
          +  changeset:   3:2ca5ba701980
          +  user:        test
          +  date:        Thu Jan 01 00:00:04 1970 +0000
          +  summary:     d
          +
             changeset:   0:9161b9aeaf16
             user:        test
             date:        Thu Jan 01 00:00:01 1970 +0000
      
      The second added test used to complain about a file not being in the parent
      revision:
      
          @@ -1638,10 +1643,8 @@
      
           Ensure that largefiles doesn't intefere with following a normal file
             $ hg  --config extensions.largefiles= log -f d -T '{desc}' -G
          -  @  c
          -  |
          -  o  a
          -
          +  abort: cannot follow file not in parent revision: ".hglf/d"
          +  [255]
             $ hg log -f d/a -T '{desc}' -G
             @  c
             |
      
      Note that there is still something fishy with the largefiles code, because when
      using a glob pattern like this:
      
          $ hg log 'glob:sub/*'
      
      the pattern list would contain '.hglf/glob:sub/*'.  None of the tests show this
      (this test lives in test-largefiles.t at 1349), it was just something that I
      noticed when the code was loaded up with print statements.
      34493912
Loading