Skip to content
Snippets Groups Projects
  1. Mar 02, 2015
  2. 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.
  3. 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
  4. Feb 18, 2015
  5. Mar 02, 2015
  6. Feb 26, 2015
  7. 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
  8. Mar 01, 2015
  9. Feb 28, 2015
  10. 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
  11. 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
  12. Feb 11, 2015
  13. Feb 02, 2015
  14. 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
  15. Feb 02, 2015
  16. Jan 31, 2015
  17. Jan 29, 2015
  18. Feb 01, 2015
  19. 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
  20. 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
  21. 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
  22. Jan 30, 2015
    • Pierre-Yves David's avatar
      discovery: properly exclude locally known but filtered heads · 3b7088a5
      Pierre-Yves David authored
      The conditional was a bit too narrow and produced buggy result when a node was
      present in both common and heads (because it pleased the discovery) and it was
      locally known but filtered.
      
      This resulted in buggy getbundle request and server side crash.
      3b7088a5
    • Pierre-Yves David's avatar
      test: make test-extdiff resilient to /usr/bin/echo · e484546a
      Pierre-Yves David authored
      My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
      e484546a
    • Pierre-Yves David's avatar
      obsstore: make the invalid markers check wrap-able · 18d43114
      Pierre-Yves David authored
      Some evolve user ignored the invalid markers for about two years and still have
      some of them in some repository. This lead to plain abort whenever mercurial try
      to open such repo. We need reinstall some way to clean this up in the evolve
      extension. For this purpose, we need the checker code wrap-able independently.
      
      This is scheduled for stable as this issue is blocking some evolve user.
      18d43114
    • Mads Kiilerich's avatar
      convert: replace revision references in messages if they are >= short hashes · c408bf3b
      Mads Kiilerich authored
      Convert will try to find references to revisions in commit messages and replace
      them with references to the converted revision. It will take any string that
      looks like a hash (and thus also decimal numbers) and look it up in the source
      repo. If it finds anything, it will use that in the commit message instead.
      
      It would do that for all hex digit sequences of 6 to 40 characters. That was
      usually no problem for small repos where it was unlikely that there would be a
      matching 6 'digit' hash prefix. It was also no problem on repos with less than
      100000 changesets where numbers with 6 or more digits not would match any
      revision number. With more than 100000 revisions random numbers in commit
      messages would be replaced with a "random" hash. For example, 'handle 100000
      requests' would be changed to to 'handle 9117c6 requests'. Convert could thus
      not really be used on real repositories with more than 100000 changesets.
      
      The default hash length shown by Mercurial is 12 'digits'. It is unexpected and
      unwanted that convert by default tries to replace revision references that use
      less than that amount of 'digits'.
      
      To fix this, don't match strings that are less than the default hash size of 12
      characters.
      c408bf3b
  23. Jan 29, 2015
    • Katsunori FUJIWARA's avatar
      merge: mark .hgsubstate as possibly dirty before submerge for consistency · 6becb9db
      Katsunori FUJIWARA authored
      Before this patch, failure of updating subrepos may cause inconsistent
      ".hgsubstate". For example:
      
        1. dirstate entry for ".hgsubstate" of the parent repo is filled
           with valid size/date (via "hg state" or so)
      
        2. "hg update" is invoked at the parent repo
      
        3. ".hgsubstate" of the parent repo is updated on the filesystem as
           a part of "g"(et) action in "merge.applyupdates"
      
        4. it is assumed that size/date of ".hgsubstate" on the filesystem
           aren't changed from ones at (1)
      
           this is not so difficult condition, because just changing hash
           ids (every ids are same in length) in ".hgsubstate" doesn't
           change the file size of it
      
        5. "subrepo.submerge()" is invoked to update subrepos
      
        6. failure of updating in one of subrepos raises exception
           (e.g. "untracked file differs")
      
        7. "hg update" is aborted without updating dirstate of the parent repo
      
           dirstate entry for ".hgsubstate" still holds size/date at (1)
      
      Then, ".hgsubstate" of the parent repo is treated as "CLEAN"
      unexpectedly, because updating ".hgsubstate" at (3) doesn't change
      size/date of it on the filesystem: see assumption at (4).
      
      This inconsistent ".hgsubstate" status causes unexpected behavior, for
      example:
      
        - "hg revert" forgets to revert ".hgsubstate"
      
        - "hg update" misunderstands that (not yet updated) subrepos diverge
          (then, it shows the prompt to confirm user's decision)
      
      To avoid inconsistent ".hgsubstate" status above, this patch marks
      ".hgsubstate" as possibly dirty before "submerge" invocation.
      "normallookup"-ed (= dirty) dirstate should be written out, even if
      processing is aborted by failure.
      
      This patch marks ".hgsubstate" as possibly dirty before "submerge",
      also when it is removed or merged while merging, for safety. This
      should prevent Mercurial from misunderstanding inconsistent
      ".hgsubstate" as clean.
      
      To satisfy conditions at (1) and (4) above, this patch uses "hg status
      --config debug.dirstate.delaywrite=2" (to fill valid size/date into
      dirstate) and "touch" (to fix date of the file).
      6becb9db
Loading