Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. Feb 11, 2015
  4. Feb 02, 2015
  5. 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
  6. Feb 02, 2015
  7. Jan 31, 2015
  8. Jan 29, 2015
  9. Feb 01, 2015
  10. Jan 30, 2015
    • Pierre-Yves David's avatar
      _adjustlinkrev: reuse ancestors set during rename detection (issue4514) · c1ce5442453f
      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.
      c1ce5442453f
    • Pierre-Yves David's avatar
      filectx: move _adjustlinkrev to a method · 087603b50889
      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.
      087603b50889
    • Katsunori FUJIWARA's avatar
      revset: raise RepoLookupError to make present() predicate continue the query · eeb5d5ab14a6
      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()".
      eeb5d5ab14a6
  11. Feb 01, 2015
    • Katsunori FUJIWARA's avatar
      templatekw: re-add showtags() to list tags keyword up in online help · 0870bb93573c
      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()".
      0870bb93573c
  12. Jan 31, 2015
    • Matt Harbison's avatar
      largefiles: don't interfere with logging normal files · 344939126579
      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.
      344939126579
  13. Jan 30, 2015
    • Pierre-Yves David's avatar
      discovery: properly exclude locally known but filtered heads · 3b7088a5c64c
      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.
      3b7088a5c64c
    • Pierre-Yves David's avatar
      test: make test-extdiff resilient to /usr/bin/echo · e484546a7c18
      Pierre-Yves David authored
      My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
      e484546a7c18
    • Pierre-Yves David's avatar
      obsstore: make the invalid markers check wrap-able · 18d431147cc1
      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.
      18d431147cc1
    • Mads Kiilerich's avatar
      convert: replace revision references in messages if they are >= short hashes · c408bf3b32f8
      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.
      c408bf3b32f8
  14. Jan 29, 2015
    • Katsunori FUJIWARA's avatar
      merge: mark .hgsubstate as possibly dirty before submerge for consistency · 6becb9dbca25
      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).
      6becb9dbca25
  15. Jan 27, 2015
    • Pierre-Yves David's avatar
      rebase: ensure rebase revision remains visible (issue4504) · 8a544fb645bb
      Pierre-Yves David authored
      Before this changeset rebase was getting very confused if any revision in the
      rebase set became hidden. This was fairly easy to achieve if a rebased revision
      was made visible by the working copy location. The rebase process would update
      somewhere else and the revision would become hidden.
      
      To work around this issue, we ensure rebased revisions remain visible for the
      whole process.
      
      This is a simple change suitable for stable. More subtle usage of unfiltered
      repository in rebase may solve this issue more cleanly.
      8a544fb645bb
  16. Jan 28, 2015
    • Mads Kiilerich's avatar
      extdiff: reintroduce backward compatibility with manual quoting of parameters · 01e5b7323a48
      Mads Kiilerich authored
      72a89cf86fcd broke things ... and the following cleanups didn't fix all issues.
      It didn't work with the diffargs shipped in mergetools.rc with explicit
      quoting. Parameters would end up with being quoted twice - especially if they
      really needed quoting.
      
      To work around that, look for explicit quotes around the variables that will be
      substituted with proper quoting. Also accept an additional prefix so we can
      handle both
        --foo='$parent'
      and
        '--foo=$parent'
      
      It will however still fail if the user intentionally place the variable inside
      a quoted string, as in
        'parent $parent is on the left'
      There is currently no good way to handle that, short of knowing exactly which
      quoting mechanism will be used.
      01e5b7323a48
    • Mads Kiilerich's avatar
      mergetools: drop incorrect quoting of diffargs variables · 6564ec382560
      Mads Kiilerich authored
      72a89cf86fcd introduced automatic quoting of diffargs in a not entirely
      backwards compatible way. That rendered some of the configuration in
      mergetools.rc invalid. It would fail when running extdiff on a single file with
      a name that needed quoting.
      
      Before:
      
        $ hg config merge-tools.meld.diffargs
        -a --label='$plabel1' $parent --label='$clabel' $child
        $ hg --config extdiff.meld= -v --debug meld
        running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ...
        meld: error: too many arguments (wanted 0-3, got 4)
      
      After:
      
        $ hg config merge-tools.meld.diffargs
        -a --label=$plabel1 $parent --label=$clabel $child
        $ hg --config extdiff.meld= -v --debug meld
        running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ...
      (success)
      6564ec382560
    • Katsunori FUJIWARA's avatar
      namespace: introduce logfmt to show l10n-ed messages for hg log correctly · 448bb32b8ee6
      Katsunori FUJIWARA authored
      Before this patch, "_()" is used incorrectly for "tag:" and
      "bookmark:" fields. "changeset_printer()" looks up keys composed at
      runtime, and it prevents "xgettext" command from getting strings to be
      translated from source files.
      
      Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
      and "bookmark:".
      
      This patch introduces "logfmt" information into "namespace" to show
      l10n-ed messages "hg log" (or "changeset_printer()") correctly.
      
      For similarity to other namespaces, this patch specifies "logfmt" for
      "branches" namespace, even though it isn't needed (branch information
      is handled in "changeset_printer()" specially).
      
      To find related code paths out easily, this patch adds "i18n: column
      positioning ..."  comment to the line composing "logfmt" by default,
      even though this line itself doesn't contain any strings to be
      translated.
      448bb32b8ee6
  17. Jan 27, 2015
  18. Jan 28, 2015
  19. Jan 27, 2015
  20. Jan 26, 2015
    • Matt Harbison's avatar
      largefiles: revert to lfilesrepo.status() being an unfiltered method · df463ca0adef
      Matt Harbison authored
      This effectively reverts 67d63ec85eb7, which caused some normal file copies to
      not be displayed as copies.  Other normal file copies could be displayed- the
      exact reason isn't clear.  This also adds two tests that were failing prior to
      this backout, so that this can be sorted out next cycle.
      
      The difference between copy cases that worked and those that didn't seemed to be
      in copies.pathcopies().  When largefiles isn't enabled for the changed test, or
      lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'.
      That wasn't true otherwise, which fell through to the _chain() method.  In this
      case, the copy is removed in the criss cross loop.
      
      'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type
      in the failing case.  I tried adding the ancestor method to the lfilesctx class
      to change the type of the ancestor context, however the context when printed as
      a string then gains a '+'.  This points to it being a context.committablectx,
      which clearly isn't correct for an ancestor.  Possibly the problem is the
      lfilesctx needs to subclass context.committablectx in some cases, but
      context.changectx in others, within the same invocation?  I'm not sure how to
      pull that off, and backing out this change is safer during the freeze.
      
      As to the status changing when a path is specified, I haven't looked into it
      yet.
      df463ca0adef
    • Matt Mackall's avatar
      test-tools: portability tweak · 0c4419faacbc
      Matt Mackall authored
      0c4419faacbc
  21. Jan 25, 2015
  22. Jan 10, 2015
Loading