D4782: remotefilelog: import pruned-down remotefilelog extension from hg-experimental

[spectral (Kyle Lippincott)]

spectral added a comment.


  My primary concern is migrating from hg-experimental remotefilelog to this.  Making one of them compatible with the other at a wire protocol level would assist with the migration immensely, so I think that avoiding complex changes to the wire protocol would make sense.  I think we should make changes to hg-experimental's remotefilelog to support any capabilities/command we implement here, so that the migration path is:
  
  1. upgrade client hg-experimental remotefilelog, it can now talk to a server using either hg-experimental or hgext/remotefilelog
  2. upgrade server - only supports hgext/remotefilelog protocol
  3. switch clients to hgext/remotefilelog
  
  (This doesn't address any migration of on-disk data structures/configuration/caches)
  
  The problem is that unless the two versions of the extension can play nicely together both being enabled in the repo at the same time, we can't just have a flag day where we change the wire protocol without a LOT of pain.

INLINE COMMENTS

> remotefilelogserver.py:208
> +            caps.append('getflogheads')
> +            caps.append('getfile')
> +        return caps

Per offline discussion, and I know this was in your TODOs in the commit description, I think we should do something like the following, but let's use the same format specifier/terminology that we're already using in other places in the wire protocol. This list is ordered in descending preference, in case that matters to the client?

  x-getfile-formats=zstd,unc,gzip,bz2

The client then issues a command like, where this formats list is unordered; the client SHOULD NOT send items not in the capabilities, but the server MUST ignore any it doesn't understand (this allows rolling upgrades where the capabilities response may be from a different, newer server).

  x-getfile path=foo/file.txt node=abc123 formats=unc,gzip

The server gets to decide what it wants to send the client: uncompressed or gzip.

Thoughts?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D4782

To: durin42, #hg-reviewers
Cc: spectral, mjpieters, mercurial-devel