Skip to content
Snippets Groups Projects
  1. Nov 14, 2017
    • 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
  2. Nov 18, 2017
  3. 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
  4. 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
  5. 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
  6. 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
  7. Nov 15, 2017
  8. Nov 14, 2017
  9. Nov 12, 2017
  10. Nov 05, 2017
  11. 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
  12. 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
  13. Nov 14, 2017
  14. Nov 17, 2017
  15. Nov 16, 2017
    • Kyle Lippincott's avatar
      run-tests: fix TESTDIR if testdescs are absolute paths · 57d56f603f70
      Kyle Lippincott authored
      Commit a18eef03d879 made TESTDIR be the location of the arguments that were
      passed to run-tests.py instead of just PWD.  It assumed that these tests were
      specified using relative paths, so if pwd was /tmp/foo, and the first argument
      was /tmp/baz, it would set TESTDIR to /tmp/foo//tmp/baz.
      
      Differential Revision: https://phab.mercurial-scm.org/D1433
      57d56f603f70
    • Anton Shestakov's avatar
      hgweb: show commit phase if it's not public · a1de4ffaa7a8
      Anton Shestakov authored
      In spartan theme phase is shown on its own table row, because there's no single
      line of "tags". Everywhere else phase is prepended to the list of "tags" of a
      changeset. Its element has a purple-ish color in gitweb and monoblue, and a
      dotted line under it and no color in paper and coal (as these themes are frugal
      with colors).
      
      This patch intentionally doesn't touch graph, because it needs a rewrite. I'll
      get to it pretty soon and in the process will add phase and everything that's
      still coming (e.g. obsolescence and instabilities).
      
      .. feature::
      
         hgweb now displays phases of non-public changesets
      a1de4ffaa7a8
  16. Nov 15, 2017
    • Anton Shestakov's avatar
      hgweb: move changeset "tags" to a template in map file (paper and coal) · 9acc0360ff67
      Anton Shestakov authored
      This patch puts all these changeset "tags" into one template shared everywhere
      in paper and coal themes. But it should be noted that some of the templates had
      different sets of tags, in some cases it was intended, in others - most likely
      not.
      
      First, what's up with all these different ways to get changeset's branch. There
      are actually 3 ways to do it in hgweb, they can all be seen in this patch;
      "branches", "inbranch" and "branch". They are all lists that consist of 1 or 0
      items:
      
      - "branches" has ctx.branch() if current changeset is the tip of that branch
      - "inbranch" has ctx.branch() if current changeset is _not_ the tip of that
        branch and the branch is not "default"
      - "branch" aka "changesetbranch" has ctx.branch() if the branch is not
        "default"
      
      The majority of cases (7 vs 2 + /graph) in paper theme used only option 3,
      which meant that "default" was never displayed. But other parts of the theme
      disagreed with this and used option 1 and option 2 together. For example, the
      default view (log) displays "default" on the branch tip (can be seen right
      about now on m-s.o/repo/hg), but it disappears when you click on the commit.
      
      Also, using option 3 alone meant that there was no way to tell if a changeset
      is the tip of its branch or not (it was always assumed that it's not, see how
      some css classes change from "branchname" to the correct "branchhead" in tests)
      -- so the two different css styles that exist in paper just for this were
      underused.
      
      I think this patch improves the situation, even though it changes the old (even
      if inconsistent) behavior. The new behavior matches that of gitweb and
      monoblue.
      9acc0360ff67
  17. Nov 03, 2017
  18. Nov 14, 2017
  19. Nov 15, 2017
  20. Oct 26, 2017
Loading