Skip to content
Snippets Groups Projects
  1. Nov 20, 2017
  2. Nov 16, 2017
  3. Nov 20, 2017
  4. Nov 16, 2017
  5. Nov 20, 2017
  6. Nov 18, 2017
    • Matt Harbison's avatar
      test-lfs: add tests demonstrating the interaction with largefiles · ec7f0bb95277
      Matt Harbison authored
      Obviously the original series needs to be accepted first, but there are concerns
      about how well these extensions will play together before proceeding.  It looks
      like the answer is surprisingly well.  There are some merge surprises
      (largefiles seems to combine the choice of "keep tracking as a large/normal
      file" with taking the content of the large/normal file) and some existing diff
      weirdness (largefiles diffs the standins, not the large file).  Converting the
      repo to normal files seemlessly transitions to lfs on the fly.  I didn't test
      going the other way, because I'm not sure why anyone would want to do that.
      
      I flagged the lack of a repo requirement after converting, because some of the
      unsubmitted changes I have add a requirement on commit, but this somehow misses
      the convert case.
      
      I flagged an issue where devel-warnings are emitted on convert, which is a
      separate issue.
      ec7f0bb95277
  7. Nov 14, 2017
    • Matt Harbison's avatar
      test-lfs: cast the flags printed to an int · eb4241f914a3
      Matt Harbison authored
      On Windows, the flag values in the subsequent tests were printing with a 'L'
      suffix.
      eb4241f914a3
    • Matt Harbison's avatar
      lfs: register config options · 07e97998d385
      Matt Harbison authored
      I'm not sure at what point we can get rid of the deprecated options, but for the
      sake of making progress, they are registered too.
      07e97998d385
    • Matt Harbison's avatar
      lfs: quiesce check-module-import warnings · b8e5fb8d2389
      Matt Harbison authored
      Specifically, 'symbol import follows non-symbol import: mercurial.i18n'
      b8e5fb8d2389
    • Matt Harbison's avatar
      lfs: import the Facebook git-lfs client extension · 66c5a8cf2868
      Matt Harbison authored
      The purpose of this is the same as the built-in largefiles extension- to handle
      huge files outside of the normal storage system, generally to keep the amount of
      data cloned to a lower amount.  There are several benefits of implementing the
      git-lfs protocol, instead of using the largefiles extension:
      
        - Bitbucket and Github support (and probably wider support in 3rd party
          hosting sites in general). [1][2]
      
        - The number of hg internals monkey patched are several orders of magnitude
          lower, so it will be easier to reason about and maintain.  Future commands
          will likely just work, without requiring various wrappers.
      
        - The "standin" files are only written to the filelog, not the disk.  That
          should avoid weird edge cases where the largefile and standin files get out
          of sync. [3]  It also avoids the occasional printing of the "hidden" standin
          file in various messages.
      
        - Filesets like size() will work, even if the file isn't present.  (It always
          says 41 bytes for largefiles, whether present or not.)
      
      The only place that I see where largefiles comes out on top is that it works
      with `hg serve` for simple sharing, without external infrastructure.  Getting
      lfs-test-server working was a hassle, and took awhile to figure out.  Maybe we
      can do something to make it work in the future.
      
      Long term, I expect that this will be highly preferred over largefiles.  But if
      we are to recommend this to largefile users, there are some UI issues to
      bikeshed.  Until they are resolved, I've marked this experimental, and am not
      putting a pointer to this in the largefiles help.  The (non exhaustive) list of
      issues I've seen so far are:
      
        - It isn't sufficient to just enable the largefiles extension- you have to
          explicitly add a file with --large before it will pay attention to the
          configured sizes and patterns on future adds.  The justification being that
          once you use it, you're stuck with it.  I've seen people confused by this,
          and haven't liked it myself.  But it's also saved me a few times.  Should we
          do something like have a specific enabling config setting that must be set
          in the local repo config, so that enabling this extension in the user or
          system hgrc doesn't silently start storing lfs files?
      
        - The largefiles extension adds a repo requirement when the first largefile is
          committed, so that the extension must always be enabled in the future.  This
          extension is not doing that, and since I only enabled it locally to avoid
          infecting other repos, I got a cryptic error about missing flag processors
          when I cloned.  Is there no repo requirement due to shallow/narrow clone
          considerations (or other future advanced things)?
      
        - In the (small amount of) reading I've done about the git implementation, it
          seems that the files and sizes are stored in a tracked .gitattributes file.
          I think a tracked file for this would be extremely useful for consistency
          across developers, but this kind of touches on the tracked hgrc file
          proposal a few months back.
      
        - The git client can specify file patterns, not just sizes.
      
        - The largefiles extension has a cache directory in the local repo, but also a
          system wide one.  We should probably implement a system wide cache too, so
          that multiple clones don't have to refetch the files from the server.
      
        - Jun mentioned other missing features, like SSH authentication, gc, etc.
      
      The code corresponds to c0492b73c7ef in hg-experimental. [4]  The only tweaks
      are to load the extension in the tests with 'lfs=' instead of
      'lfs=$TESTDIR/../hgext3rd/lfs', change the import in the *.py test to hgext
      (from hgext3rd), add the 'testedwith' declaration, and mark it experimental for
      now.  The infinite-push, p4fastimport, and remotefilelog tests were left behind.
      
      The devel-warnings for unregistered config options are not corrected yet, nor
      are the import check warnings.
      
      [1] https://www.mercurial-scm.org/pipermail/mercurial/2017-November/050699.html
      [2] https://bitbucket.org/site/master/issues/3843/largefiles-support-bb-3903
      [3] https://bz.mercurial-scm.org/show_bug.cgi?id=5738
      [4] https://bitbucket.org/facebook/hg-experimental
      66c5a8cf2868
  8. Nov 18, 2017
  9. Nov 20, 2017
    • Anton Shestakov's avatar
      hgweb: use webutil.commonentry() for nodes (but not for jsdata yet) in /graph · 23bba755cf80
      Anton Shestakov authored
      This makes graphdata() simpler by using existing code that gets common
      changeset properties for showing in hgweb. graphdata() is a nested function in
      graph() that prepares entries for /graph view, but there are two different
      lists of changesets prepared: "jsdata" for JavaScript-rendered graph and
      "nodes" for everything else.
      
      For "jsdata", properties "node", "user", "age" and "desc" are passed through
      various template filters because we don't have these filters in JavaScript, so
      the data has to be prepared server-side. But now that commonentry() is used for
      producing "nodes" list (and it doesn't apply any filters), these filters need
      to be added to the appropriate templates (only raw at this moment, everything
      else either doesn't implement graph or uses JavaScript).
      
      This is a bit of refactoring that will hopefully simplify future patches. The
      end result is to have /graph that only renders the actual graph with nodes and
      vertices in JavaScript, and the rest is done server-side. This way server-side
      code can focus on showing a list of changesets, which is easy because we
      already have /log, /shortlog, etc, and JavaScript code can be simplified,
      making it easier to add obsolescence graph and other features.
      23bba755cf80
    • Anton Shestakov's avatar
      hgweb: check changeset's original branch in graphdata() · 4bc74bc78efd
      Anton Shestakov authored
      This piece of code checks if a changeset is the tip of its branch, but as can
      be seen above in the context, "branch" was prepared for being displayed in
      hgweb by making it unicode and passing it through url.escape. It's better to
      use the original ctx.branch().
      4bc74bc78efd
  10. Nov 19, 2017
    • Anton Shestakov's avatar
      hgweb: show instabilities of a commit · 38fe3fe4bbb6
      Anton Shestakov authored
      In paper, coal, gitweb and monoblue a new "tag" (or multiple, if there are many
      instabilities) is added to the same line that has phase, branch, etc of a
      changeset; in gitweb and monoblue this element has a light red background, in
      paper and coal the element is black and underlined. In spartan theme
      instabilities are shown on a separate line.
      
      While test-obsolete.t uses first(phasedivergent()) revset to pick a changeset
      to test, that particular changeset is also an orphan, so two different
      instability tags are displayed.
      38fe3fe4bbb6
    • Anton Shestakov's avatar
      context: add instabilities() method to basefilectx · bd2743936b56
      Anton Shestakov authored
      This method is now used in webutils.commonentry(), which adds common data items
      (commit hash, author, date, etc) for rendering changesets in hgweb. Usually,
      commonentry() is given a changectx as ctx; but in views related to files (e.g.
      file view, diff, annotate) it's replaced by a filectx, so the latter also needs
      to have instabilities() method.
      bd2743936b56
    • Boris Feld's avatar
      run-test: drop 'execfile' usage for 'common-pattern.py' file · 1ac4c0887de4
      Boris Feld authored
      This is required for Python 3.
      1ac4c0887de4
    • Boris Feld's avatar
      run-test: use byte for 'common-pattern.py' path · 6a8e85702121
      Boris Feld authored
      This is required for Python 3.
      6a8e85702121
  11. Nov 20, 2017
    • Jordi Gutiérrez Hermoso's avatar
      templates: reword 'back to filelog' link anchor text · 79cbf5cc4fb8
      Jordi Gutiérrez Hermoso authored
      This anchor text is problematic in two ways: first, the "back to" part
      assumes that you got to the page showing it via the filelog. This is
      not necessarily true, as there are other ways to get to that view
      besides the filelog view, such as for example following the history of
      lines from a file. Second, it uses "filelog" jargon, which refers to
      how each file has its own revlog. This is internal jargon that has no
      business being exposed to the end user.
      
      I just reworded this template to improve understanding.
      79cbf5cc4fb8
  12. Nov 18, 2017
    • Anton Shestakov's avatar
      hgweb: show obsolescence status of a commit · 69ea10d5b00c
      Anton Shestakov authored
      As with phases, spartan theme shows a simple "obsolete: yes" on its own line
      (this allows replacing "yes" with something more useful in future, like output
      of obsfate* template functions). Everywhere else a new "tag" is added to the
      same line that has phase, branch, etc of a changeset; in gitweb and monoblue
      the element has gray background, in paper and coal the element is gray with a
      dashed underline.
      69ea10d5b00c
    • Anton Shestakov's avatar
      context: add obsolete() method to basefilectx · a9454beb9dd8
      Anton Shestakov authored
      This method is now used in webutils.commonentry(), which adds common data items
      (commit hash, author, date, etc) for rendering changesets in hgweb. Usually,
      commonentry() is given a changectx as ctx; but in views related to files (e.g.
      file view, diff, annotate) it's replaced by a filectx, so the latter also needs
      to have obsolete() method.
      a9454beb9dd8
    • Anton Shestakov's avatar
      check-code: grep's context flags don't need an extra space before number · dd000a958364
      Anton Shestakov authored
      A bit of useless trivia found while researching this: OpenBSD's grep's -C has a
      default value (of 2) and disallows space before the argument (while -A and -B
      allow).
      dd000a958364
  13. Nov 15, 2017
  14. Nov 14, 2017
  15. Nov 12, 2017
  16. Nov 05, 2017
  17. Nov 13, 2017
    • Boris Feld's avatar
      test-pattern: register the current the bundle2 capabilities string · c4ec72a10798
      Boris Feld authored
      The bundle capabilites are sent with every getbundle ssh connection. Every time
      the protocol is updated, that string is altered. We get the part about bundle2
      string replaced by $USUAL_BUNDLE2_CAPS$ so that we only have to change the
      substitution whenever this happens.
      c4ec72a10798
  18. Nov 05, 2017
    • Boris Feld's avatar
      test-pattern: register current the bundlecaps string · b4767ae63b32
      Boris Feld authored
      The bundle capabilites sent with every getbundle commands. Every time the
      protocol is updated, that string is altered. We get that string replace by
      $USUAL_BUNDLE_CAPS$ so that we only have to change the substitution whenever
      this happens.
      b4767ae63b32
    • Boris Feld's avatar
      test-pattern: substitute common compression list · 3abdd7da33bd
      Boris Feld authored
      The compression list as to be matched with a glob because zstd might not be part
      of the option. By using a substitution for these, we won't have to re-glob them
      over and over.
      3abdd7da33bd
    • Boris Feld's avatar
      run-tests: allow to register any arbitrary pattern for replacement · 4fb489a998c9
      Boris Feld authored
      We add a 'common-pattern.py' file that allow to define extra pattern. This seems
      a cleaner approach than editing the 'run-test.py' file over and over. In
      addition allowing arbitrary pattern registration will also help extension.
      
      The format used is a python file is picked out of convenience defining a list of
      tuple in 'substitutions' variable. This is picked out of convenience since it is
      dead simple to implement.
      
      The end goal is to register more pattern for Mercurial test. There are multiple
      common patterns that change over time. That impact is annoying. Using pattern
      emplacement for them would be handy.
      
      The next patches will define all the needed patterns and the last patch will
      mass-update the tests outputs as it was easier to do in a single pass.
      4fb489a998c9
Loading