Skip to content
Snippets Groups Projects
  1. Apr 08, 2018
    • Matt Harbison's avatar
      lfs: infer the blob store URL from paths.default · 092eff6833a7
      Matt Harbison authored
      If `lfs.url` is specified, it takes precedence.  However, now that we support
      serving blobs via hgweb, we shouldn't *require* this setting.  Less
      configuration is better (things will work out of the box once this is sorted
      out), and git has similar functionality.
      
      This is not a complete solution- it isn't able to infer the blob store from an
      explicitly supplied path, and it should consider `paths.default-push` for push.
      The pull solution for that is a bit hacky, and this alone is an improvement for
      the vast majority of cases.
      
      Even though there are only a handful of references to the saved remote store,
      the location of them makes things complicated.
      
        1) downloading files on demand in the revlog flag processor
        2) copying to readonlyvfs with bundlerepo
        3) downloading in the file prefetch hook
        4) the canupload()/skipdownload() checks
        5) uploading blobs
      
      Since revlog doesn't have a repo or ui reference, we can't avoid creating a
      remote store when the extension is loaded.  While the long term goal is to make
      sure the prefetch hook is invoked early for every command for efficiency, this
      handling in the flag processor is needed as a last ditch fetch.
      
      In order to support the clone command, the remote store needs to be created
      later than when the extension loads, since `paths.default` isn't set until just
      before the files are checked out.  Therefore, this patch changes the prefetch
      hook to ignore the saved reference, and build a new one.
      
      The canupload()/skipdownload() checks simply check if the stored instance is a
      `_nullremote`.  Since this can only be set via `lfs.url` (which is reflected in
      the saved reference), checking only the instance created when the extension
      loaded is fine.
      
      The blob uploading function is called from several places:
      
        1) a prepush hook
        2) when writing a new bundle
        3) from infinitepush
      
      The prepush hook gets an exchange.pushop, so it has a path to where the push is
      going.  The bundle writer and infinitepush don't.  Further, bundle creation for
      things like strip and amend are causing blobs to be uploaded.  This seems wrong,
      but I don't want to side track this sorting that out, so punt on trying to
      handle explicit push paths or `paths.default-push`.
      
      I also think that sending blobs to a remote store when pushing to a local repo
      is wrong.  This functionality predates the usercache, so perhaps that's the
      reason for it.  I've got some patches floating around to stop sending blobs
      remotely in this case, and instead write directly to the other repo's blob
      store.  But the tests for corruption handling weren't happy with this change,
      and I don't have time to rewrite them.  So exclude filesystem based paths from
      this for now.
      
      I don't think there's much of a chance to implement `paths.remote:lfsurl` style
      configs, given how early these are resolved vs how late the remote store is
      created.  But git has it, so I threw a TODO in there, in case anyone has ideas.
      
      I have no idea why this is now doing http auth twice when it wasn't before.  I
      don't think the original blobstore's url is ever being used in these cases.
      092eff6833a7
    • Matt Harbison's avatar
      lfs: add the ability to disable the usercache · 491edf2435a0
      Matt Harbison authored
      While the usercache is important for real world uses, I've been tripped up more
      than a couple of times by it in tests- thinking a file was being downloaded, but
      it was simply linked from the local cache.  The syntax for setting it is the
      same as for setting a null remote endpoint, and like that endpoint, is left
      undocumented.
      
      This may or may not be a useful feature in the real world (I'd expect any sane
      filesystem to support hardlinks at this point).
      491edf2435a0
  2. Apr 11, 2018
  3. Apr 01, 2018
  4. Apr 06, 2018
  5. Apr 08, 2018
  6. Mar 19, 2018
    • Yuya Nishihara's avatar
      templatekw: fix return type of {succsandmarkers} (BC) · 49a8c2cc7978
      Yuya Nishihara authored
      A hybrid object represents a list/dict of values, but {succsandmarkers}
      returns a list of template mappings.
      
      This change means old-style list templates (e.g. "start_succsandmarkers")
      are no longer supported, but that should be okay since {succsandmarkers}
      is still experimental and relatively new.
      49a8c2cc7978
  7. Mar 17, 2018
  8. Mar 15, 2018
  9. Mar 18, 2018
  10. Jan 18, 2018
    • Jörg Sonnenberger's avatar
      wireproto: support for pullbundles · aacfca6f9767
      Jörg Sonnenberger authored
      Pullbundles are similar to clonebundles, but served as normal inline
      bundle streams. They are almost transparent to the client -- the only
      visible effect is that the client might get less changes than what it
      asked for, i.e. not all requested head revisions are provided.
      
      The client announces support for the necessary retries with the
      partial-pull capability. After receiving a partial bundle, it updates
      the set of revisions shared with the server and drops all now-known
      heads from the request list. It will then rerun getbundle until
      no changes are received or all remote heads are present.
      
      Extend badserverext to support per-socket limit, i.e. don't assume that
      the same limits should be applied to all sockets.
      
      Differential Revision: https://phab.mercurial-scm.org/D1856
      aacfca6f9767
  11. Apr 07, 2018
    • Gregory Szorc's avatar
      filelog: wrap revlog instead of inheriting it (API) · 1541e1a8e87d
      Gregory Szorc authored
      The revlog base class exposes a ton of methods. Inheriting the
      revlog class for filelog will make it difficult to expose a
      clean interface. There will be abstraction violations.
      
      This commit breaks the inheritance of revlog by the filelog
      class. Filelog instances now contain a reference to a revlog
      instance. Various properties and methods are now proxied to
      that instance.
      
      There is precedence for doing this: manifestlog does something
      similar. Although, manifestlog has a cleaner interface than
      filelog. We'll get there with filelog...
      
      The new filelog class exposes a handful of extra properties and
      methods that aren't part of the declared filelog interface.
      Every extra item was added in order to get a test to pass. The
      set of tests that failed without these extra proxies has
      significant overlap with the set of tests that don't work with
      the simple store repo. There should be no surprise there.
      
      Hopefully the hardest part about this commit to review are the
      changes to bundlerepo and unionrepo. Both repository types
      define a custom revlog or revlog-like class and then have a
      custom filelog that inherits from both filelog and their custom
      revlog. This code has been changed so the filelog types don't
      inherit from revlog. Instead, they replace the revlog instance
      on the created filelog. This is super hacky. I plan to fix this
      in a future commit by parameterizing filelog.__init__.
      
      Because Python function call overhead is a thing, this change
      could impact performance by introducing a nearly empty proxy
      function for various methods and properties. I would gladly
      measure the performance impact of it, but I'm not sure what
      operations have tight loops over filelog attribute lookups
      or function calls. I know some of the DAG traversal code can
      be sensitive about the performance of e.g. parentrevs(). However,
      many of these functions are implemented on the revlog class and
      therefore have direct access to self.parentrevs() and aren't
      going through a proxy.
      
      .. api::
      
         filelog.filelog is now a standalone class and doesn't inherit
         from revlog. Instead, it wraps a revlog instance at self._revlog.
         This change was made in an attempt to formalize storage APIs and
         prevent revlog implementation details leaking through to callers.
      
      Differential Revision: https://phab.mercurial-scm.org/D3154
      1541e1a8e87d
  12. Apr 09, 2018
  13. Apr 07, 2018
    • Jörg Sonnenberger's avatar
      revlog: reset _nodepos after strip · 1ce7a55b09d1
      Jörg Sonnenberger authored
      When using the pure revlog parser, _nodepos is used to keep track of the
      position during index scanning in the non-cached cache. If it is out of
      bounds, BaseIndexObject._fix_index will assert. Since strip can actually
      remove the position scanned last, make sure to reset it. Add an
      assertion in the place where the invariance is clearer.
      
      Differential Revision: https://phab.mercurial-scm.org/D3188
      1ce7a55b09d1
  14. Apr 04, 2018
    • Anton Shestakov's avatar
      paper: make all source lines have the same minimum height · f1413e4a54a6
      Anton Shestakov authored
      Empty source lines in paper and coal themes used to have smaller height than
      every other line (because of the way line numbers are shown and because they
      are using smaller font). This wasn't very noticeable before the follow lines
      functionality was added, but after that just using the follow-lines button to
      select a block of code with empty lines would demonstrate the fact that empty
      lines didn't have enough height - there were white "gaps" in the selection
      block.
      
      Since this problem occurs when lines don't have any content inside, let's
      create a pseudo-element (it's unselectable because of that) which still doesn't
      have any content, but fills up empty lines to 100% of their height because of
      display: inline-block. This is the most natural way to solve this annoyance
      that I've found so far.
      
      Hardcoding height isn't useful because we can have wrapped lines, in which case
      multiple lines of text need to fit into a single <span>.
      
      Setting min-height or line-height doesn't remove the gaps when viewed in
      Chromium.
      f1413e4a54a6
  15. Apr 08, 2018
    • Anton Shestakov's avatar
      hgweb: make followlines button absolutely positioned · 8d05938dd063
      Anton Shestakov authored
      It used to have position: absolute only on annotate page, but it makes sense to
      have it everywhere, because the button shouldn't affect other elements at all.
      Especially since the button has a set height, which meant that for certain
      smaller fonts source lines were changing their height on hover.
      
      Note that the button doesn't set any of the usual properties that accompany
      absolute position (top, right, bottom or left). These properties would position
      the button without any account for source line padding. Instead, margins are
      used (the button already has all margins defined, they do the job).
      8d05938dd063
  16. Apr 09, 2018
    • Anton Shestakov's avatar
      hgweb: insert followlines buttons before any children, including text nodes · 685ad41feba0
      Anton Shestakov authored
      This way the buttons come before any other content, including text nodes.
      Because highlight extension replaces every line of text with some <span>
      elements that have CSS classes for highlighting, the placement of followlines
      buttons used to depend on if that extension was enabled or not. Let's make the
      placement more consistent, it'll help the next patch in this series.
      685ad41feba0
  17. Mar 28, 2018
    • Gregory Szorc's avatar
      wireproto: only expose "debugwireargs" to version 1 transports · 3a91911c4343
      Gregory Szorc authored
      I'm not even sure this command should be enabled for version 1
      transports. It is just a reflection endpoint for argument data.
      We definitely don't need to support it in version 2.
      
      Differential Revision: https://phab.mercurial-scm.org/D3184
      3a91911c4343
    • Gregory Szorc's avatar
      wireproto: only expose "hello" command to version 1 transports · 6e6d68c2d39c
      Gregory Szorc authored
      This command is only ever used for the handshake in the SSH protocol.
      We probably don't even need for it to be a proper command. Let's not
      carry it forward to version 2 because I don't see a use for it there.
      
      Differential Revision: https://phab.mercurial-scm.org/D3183
      6e6d68c2d39c
    • Gregory Szorc's avatar
      wireproto: port branchmap to wire protocol v2 · 3b99eb028859
      Gregory Szorc authored
      Differential Revision: https://phab.mercurial-scm.org/D3182
      3b99eb028859
    • Gregory Szorc's avatar
      68915b9f8e96
    • Gregory Szorc's avatar
      wireproto: port keep command to wire protocol v2 · 6847542bb8d7
      Gregory Szorc authored
      This is pretty straightforward.
      
      Differential Revision: https://phab.mercurial-scm.org/D3180
      6847542bb8d7
    • Gregory Szorc's avatar
      wireproto: port heads command to wire protocol v2 · 0b7475ea38cf
      Gregory Szorc authored
      After much thought and consideration, wire protocol version 2's
      commands will be defined in different functions from the existing
      commands. This will make it easier to implement these commands
      because it won't require shoehorning things like response formatting
      and argument declaration into the same APIs.
      
      For example, wire protocol version 1 requires that commands declare
      a fixed and ordered list of argument names. It isn't really possible
      to insert new arguments or have optional arguments without
      breaking backwards compatibility. Wire protocol version 2, however,
      uses CBOR maps for passing arguments. So arguments a) can be
      optional b) can be added without BC c) can be strongly typed.
      
      This commit starts our trek towards reimplementing the wire protocol
      for version 2 with the heads command. It is pretty similar to the
      existing heads command. One added feature is it can be told to
      operate on only public phase changesets. This is useful for
      making discovery faster when a repo has tens of thousands of
      draft phase heads (such as Mozilla's "try" repository).
      
      The HTTPv2 server-side protocol has had its `getargs()` implementation
      updated to reflect that arguments are a map and not a list.
      
      Differential Revision: https://phab.mercurial-scm.org/D3179
      0b7475ea38cf
    • Gregory Szorc's avatar
      largefiles: wrap heads command handler more directly · c22fd3c4c23e
      Gregory Szorc authored
      extensions.wrapfunction() is a more robust method for wrapping a
      function, since it allows multiple wrappers.
      
      While we're here, wrap the function registered with the command instead
      of installing a new command handler.
      
      Differential Revision: https://phab.mercurial-scm.org/D3178
      c22fd3c4c23e
    • Gregory Szorc's avatar
      wireproto: crude support for version 2 HTTP peer · 61e405fb6372
      Gregory Szorc authored
      As part of implementing the server-side bits of the wire protocol
      command handlers for version 2, we want a way to easily test those
      commands. Currently, we use the "httprequest" action of `hg
      debugwireproto`. But this requires explicitly specifying the HTTP
      request headers, low-level frame details, and the data structure
      to encode with CBOR. That's a lot of boilerplate and a lot of it can
      change as the wire protocol evolves.
      
      `hg debugwireproto` has a mechanism to issue commands via the peer
      interface. That is *much* easier to use and we prefer to test with
      that going forward.
      
      This commit implements enough parts of the peer API to send basic
      requests via the HTTP version 2 transport.
      
      The peer code is super hacky. Again, the goal is to facilitate
      server testing, not robustly implement a client. The client code
      will receive love at a later time.
      
      Differential Revision: https://phab.mercurial-scm.org/D3177
      61e405fb6372
  18. Mar 26, 2018
  19. Apr 08, 2018
Loading