Skip to content
Snippets Groups Projects
  1. Jun 17, 2015
  2. Jun 18, 2015
  3. Jun 17, 2015
  4. Jun 15, 2015
  5. Jun 17, 2015
    • Matt Harbison's avatar
      test-subrepo-recursion: more aggressively regex 'unzip -l' output for 10.10 · 37876ca00c0a
      Matt Harbison authored
      The output on 10.10 looks like this:
      
          Length     Date   Time    Name
         --------    ----   ----    ----
              172  01-01-80 00:00   .hg_archival.txt
               10  01-01-80 00:00   .hgsub
               45  01-01-80 00:00   .hgsubstate
                3  01-01-80 00:00   x.txt
               10  01-01-80 00:00   foo/.hgsub
               45  01-01-80 00:00   foo/.hgsubstate
                9  01-01-80 00:00   foo/y.txt
                9  01-01-80 00:00   foo/bar/z.txt
         --------                   -------
              303                   8 files
      
      (2 digit year, shorter -- separators and closer columns).  We don't care about
      any of that, so ignore it.
      37876ca00c0a
    • Pierre-Yves David's avatar
      contrib: introduce an all-revsets.txt file · 67a2192dcb64
      Pierre-Yves David authored
      This file should gather all revsets ever thought interesting by
      anyone. That way one can check the impact of a change when touching
      something revset-ish. See inline comments for details.
      
      This file have been refilled with all the entry I could automatically
      find from changeset descriptions. I assume we missed some not using
      'revsetbenchmarks.py' output.
      67a2192dcb64
    • Pierre-Yves David's avatar
      contrib: rename revsetbenchmarks.txt to 'base-revsets.txt' · 2fea23d035d8
      Pierre-Yves David authored
      We rename the file and document its purpose. We'll be introducing another file
      gathering revsets useful for benchmark of the predicate themsleves in a coming
      changesets.
      2fea23d035d8
    • Pierre-Yves David's avatar
      revsetbenchmarks: add main documention for the script · ddb2a648fdbd
      Pierre-Yves David authored
      This allow us to document the fact we can use comment in the file listing revsets.
      ddb2a648fdbd
  6. Jun 16, 2015
    • Anton Shestakov's avatar
      hgweb: don't dereference symbolic revision in paper & coal style (issue2296) · 3bb6f5f478a7
      Anton Shestakov authored
      Let's make paper (and coal, since it borrows so much from paper) templates use
      symbolic revision in navigation links.
      
      The majority of links (log, filelog, annotate, etc) still use node hashes.
      
      Some pages don't have permanent links to current node hash (so it's not very
      easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
      patches.
      3bb6f5f478a7
    • Anton Shestakov's avatar
      hgweb: don't dereference symbolic revision in gitweb style · dd89304687a3
      Anton Shestakov authored
      Let's make gitweb templates use symbolic revision in navigation links.
      
      The majority of links (log, filelog, annotate, etc) still use node hashes.
      
      Some pages don't have permanent links to current node hash (so it's not very
      easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
      patches.
      dd89304687a3
    • Anton Shestakov's avatar
      hgweb: don't dereference symbolic revision in monoblue style · 0cdcbc477cac
      Anton Shestakov authored
      Let's make monoblue templates use symbolic revision in navigation links.
      
      The majority of links (log, filelog, annotate, etc) still use node hashes.
      
      Some pages don't have permanent links to current node hash (so it's not very
      easy to go from /rev/tip to /rev/<tip hash>), this will be addressed in future
      patches.
      0cdcbc477cac
    • Anton Shestakov's avatar
      hgweb: don't dereference symbolic revision in spartan style · 1cac419ab831
      Anton Shestakov authored
      Let's make spartan templates use symbolic revision in navigation links.
      
      The majority of links (log, filelog, annotate, etc) still use node hashes, and
      many pages also have permanent link to current node hash (i.e. you can go from
      /rev/tip to /rev/<tip hash> without manual url editing), so it's safe to
      update navigation.
      1cac419ab831
  7. Jun 15, 2015
    • Anton Shestakov's avatar
      hgweb: provide symrev (symbolic revision) property to the templates · 85fb416f2fa7
      Anton Shestakov authored
      One of the features of hgweb is that current position in repo history is
      remembered between separate requests. That is, links from /rev/<node_hash> lead
      to /file/<node_hash> or /log/<node_hash>, so it's easy to dig deep into the
      history. However, such links could only use node hashes and local revision
      numbers, so while staying at one exact revision is easy, staying on top of the
      changes is not, because hashes presumably can't change (local revision numbers
      can, but probably not in a way you'd find useful for navigating).
      
      So while you could use 'tip' or 'default' in a url, links on that page would be
      permanent. This is not always desired (think /rev/tip or /graph/stable or
      /log/@) and is sometimes just confusing (i.e. /log/<not the tip hash>, when
      recent history is not displayed). And if user changed url deliberately to say
      default instead of <some node hash>, the page ignores that fact and uses node
      hash in its links, which means that navigation is, in a way, broken.
      
      This new property, symrev, is used for storing current revision the way it was
      specified, so then templates can use it in links and thus "not dereference" the
      symbolic revision. It is an additional way to produce links, so not every link
      needs to drop {node|short} in favor of {symrev}, many will still use node hash
      (log and filelog entries, annotate lines, etc).
      
      Some pages (e.g. summary, tags) always use the tip changeset for their context,
      in such cases symrev is set to 'tip'. This is needed in case the pages want to
      provide archive links.
      
      highlight extension needs to be updated, since _filerevision now takes an
      additional positional argument (signature "web, req, tmpl" is used by most of
      webcommands.py functions).
      
      More references to symbolic revisions and related gripes: issue2296, issue2826,
      issue3594, issue3634.
      85fb416f2fa7
  8. Jun 17, 2015
    • Matt Harbison's avatar
      archive: support 'wdir()' · 3ec8351fa6ed
      Matt Harbison authored
      This is a step toward replacing the extdiff internals with archive, in order to
      support 'extdiff -S'.  Only Mercurial subrepos are supported for now.
      
      If a file is missing from the filesystem, it is silently skipped.  Perhaps it
      should warn, but it cannot abort when working with extdiff because deleting a
      file is a legitimate diff.
      3ec8351fa6ed
    • Matt Harbison's avatar
      subrepo: allow a representation of the working directory subrepo · 70ac1868b707
      Matt Harbison authored
      Some code cannot handle a subrepo based on the working directory (e.g.
      sub.dirty()), so the caller must opt in.  This will be useful for archive, and
      perhaps some other commands.  The git and svn methods where this is used may
      need to be fixed up on a case by case basis.
      70ac1868b707
  9. Jun 16, 2015
    • Yuya Nishihara's avatar
      templater: comment that gettemplate() has different name resolution order · 695b93a79d17
      Yuya Nishihara authored
      I've tried to unify gettemplate() with buildtemplate(), but it didn't go well
      because gettemplate() have to bypass mapping dict.
      
      For example, web templates have '{tags%changelogtag}' and 'changelogtag' is
      defined in both mapping, the default, and context.cache, sourced from map file.
      In general, mapping shadows context variables, but gettemplate() have to pick
      it from context.cache.
      695b93a79d17
  10. Jun 13, 2015
  11. Jun 10, 2015
  12. Jun 13, 2015
    • Yuya Nishihara's avatar
      templater: take any string literals as template, but not for rawstring (BC) · c1975809a6b5
      Yuya Nishihara authored
      This patch series is intended to unify the interpretation of string literals.
      It is breaking change that boldly assumes
      
       a. string literal "..." never contains template-like fragment or it is
          intended to be a template
       b. we tend to use raw string literal r"..." for regexp pattern in which "{"
          should have different meaning
      
      Currently, we don't have a comprehensible rule how string literals are
      evaluated in template functions. For example, fill() takes "initialindent"
      and "hangindent" as templates, but not for "text", whereas "text" is a
      template in pad() function.
      
        date(date, fmt)
        diff(includepattern, excludepattern)
        fill(text, width, initialident: T, hangindent: T)
        get(dict, key)
        if(expr, then: T, else: T)
        ifcontains(search, thing, then: T, else: T)
        ifeq(expr1, expr2, then: T, else: T)
        indent(text, indentchars, firstline)
        join(list, sep)
        label(label: T, expr: T)
        pad(text: T, width, fillchar, right)
        revset(query, formatargs...])
        rstdoc(text, style)
        shortest(node, minlength)
        startswith(pattern, text)
        strip(text, chars)
        sub(pattern, replacement, expression: T)
        word(number, text, separator)
        expr % template: T
      
        T: interpret "string" or r"rawstring" as template
      
      This patch series adjusts the rule as follows:
      
       a. string literal, '' or "", starts template processing (BC)
       b. raw string literal, r'' or r"", disables both \-escape and template
          processing (BC, done by subsequent patches)
       c. fragment not surrounded by {} is non-templated string
      
        "ccc{'aaa'}{r'bbb'}"
         ------------------  *: template
         ---                 c: string
              ---            a: template
                      ---    b: rawstring
      
      Because this can eliminate the compilation of template arguments from the
      evaluation phase, "hg log -Tdefault" gets faster.
      
        % cd mozilla-central
        % LANG=C HGRCPATH=/dev/null hg log -Tdefault -r0:10000 --time > /dev/null
        before: real 4.870 secs (user 4.860+0.000 sys 0.010+0.000)
        after:  real 3.480 secs (user 3.440+0.000 sys 0.030+0.000)
      
      Also, this will allow us to parse nested templates at once for better error
      indication.
      c1975809a6b5
  13. Jun 12, 2015
  14. Jun 15, 2015
  15. Jun 16, 2015
    • Matt Harbison's avatar
      verify: check the subrepository references in .hgsubstate · f1d46075b13a
      Matt Harbison authored
      While hopefully atypical, there are reasons that a subrepository revision can be
      lost that aren't covered by corruption of the .hgsubstate revlog.  Such things
      can happen when a subrepo is amended, stripped or simply isn't pulled from
      upstream because the parent repo revision wasn't updated yet.  There's no way to
      know if it is an error, but this will find potential problems sooner than when
      some random revision is updated.
      
      Until recently, convert made no attempt at rewriting the .hgsubstate file.  The
      impetuous for this is to verify the conversion of some repositories, and this is
      orders of magnitude faster than a bash script from 0..tip that does an
      'hg update -C $rev'.  But it is equally useful to determine if everything has
      been pulled down before taking a thumb drive on the go.
      
      It feels somewhat wrong to leave this out of verifymod (mostly because the file
      is already read in there, and the final summary is printed before the subrepos
      are checked).  But verifymod looks very low level, so importing subrepo stuff
      there seems more wrong.
      f1d46075b13a
  16. Jun 15, 2015
    • Matt Harbison's avatar
      context: override workingctx.hex() to avoid a crash · 183965a00c76
      Matt Harbison authored
      Since node is None for workingctx, it can't use the base class
      implementation of 'hex(self.node())'.
      
      It doesn't appear that there are any current callers of this, but there will be
      when archive supports 'wdir()'.  My first thought was to use "{p1node}+", but
      that would cause headaches elsewhere [1].
      
      We should probably fix up localrepository.__getitem__ to accept this hash for
      consistency, as a followup.  This works, if the full hash is specified:
      
        @@ -480,7 +480,7 @@
                 return dirstate.dirstate(self.vfs, self.ui, self.root, validate)
      
             def __getitem__(self, changeid):
        -        if changeid is None:
        +        if changeid is None or changeid == 'ff' * 20:
                     return context.workingctx(self)
                 if isinstance(changeid, slice):
                     return [context.changectx(self, i)
      
      That differs from null, where it will accept any number of 0s, as long as it
      isn't ambiguous.
      
      
      [1] https://www.selenic.com/pipermail/mercurial-devel/2015-June/071166.html
      183965a00c76
    • Matt Harbison's avatar
  17. Jun 16, 2015
  18. Jun 03, 2015
    • Anton Shestakov's avatar
      tests: test symbolic revision (de)reference in all hgweb styles · e7455316261d
      Anton Shestakov authored
      Right now the way revisions get specified in hgweb urls is ignored, i.e. after
      revision is resolved, only its node hash (or sometimes local revision number)
      is used for all links in the templates. So, basically, every page for "tip"
      revision (or any other symbolic rev id) will dereference it: lose the nice
      symbolic name by putting node hash/local rev number in its place. The only
      exception so far is archive links on some pages: /archive/tip.{bz2,gz,zip}.
      
      The fact that this dereferencing is neither convenient nor intuitive is
      reflected in issue2296, issue2826 and issue3594. issue3634 also mentions this.
      But to fix this it's first needed to demonstrate and test the way templates
      currently form links.
      
      The new test file is separate from other hgweb tests, since it seems big and
      distinct enough. And it's so big because links are formed in each template
      independently, so it's necessary to test them all to avoid any inconsistent
      behavior.
      e7455316261d
  19. Jun 16, 2015
  20. Jun 15, 2015
  21. May 27, 2015
    • Martin von Zweigbergk's avatar
      match: don't remove '.' from _includeroots · b76410eed482
      Martin von Zweigbergk authored
      This makes _includeroots more like _fileroots and gives visitdir() a
      nice symmetry in the two.
      
      I'm hoping to later combine the two (_fileroots and _includeroots),
      and having them treated similarly should make that step easier to
      follow.
      b76410eed482
Loading