Upstreaming Facebook extensions
David Soria Parra
david.soriaparra at oculus.com
Thu Nov 16 12:05:18 EST 2017
Already commented on this. We use this day-to-day and it seems to be solid. A few things:
- The progress bar gets confused by downloads, as those are done one by one. We need to improve how we show the amount of lfs files and the bytes to download. Something we can figure out while upstreaming
- Resumable Downloads:
- We don’t support that yet. Should be in there, but not urgent for upstreaming.
- Additional consistency checks:
- We know that somehow it can happen that a file only gets partially downloaded. We need to better consistency check before upstreaming.
- Interaction with largefiles
- We need a consistent story how to get from largefiles to LFS and back. Alternatively we can just say “you can’t use LFS if you used largefiles”.
On 11/16/17, 5:56 PM, "Durham Goode" <durham at fb.com> wrote:
On 11/14/17 8:26 AM, Augie Fackler wrote:
>> On Nov 13, 2017, at 22:49, Matt Harbison <mharbison72 at gmail.com> wrote:
>> On Mon, 13 Nov 2017 22:12:31 -0500, Jun Wu <quark at fb.com> wrote:
>>> Excerpts from Matt Harbison's message of 2017-11-13 21:50:29 -0500:
>>> For LFS, it has been used in a repo synced from p4 for about half a year.
>>> It's mostly good except for lack of features (ex. support the Git-LFS SSH
>>> authentication, support gc, etc.). It was actually written with some extra
>>> care of upstream-friendliness. For example, I put remotefilelog integration
>>> in remotefilelog instead of LFS intentionally.
>>> Help is definitely welcomed!
>> OK, good to know.
>> So is upstreaming lfs in a single patch and marking it experimental a reasonable next step, or does this need to incubate in hg-experimental a bit more? I didn't get it working outside of the tests (it said something about not having a common changegroup version), but it looks like there's some low hanging fruit like registering the config options, and tracking down some warning in url.py about an "unquoted realm" or similar.
>> I know BC doesn't apply to experimental things, but realistically, I assume things won't need to change other that maybe config stuff to add features? I wouldn't mind using this sooner rather than later if the files can always be retrieved.
> My sense of lfs is that it's a much better overall approach to largefiles handling, and that we should probably work to get it in core sooner rather than later as long as Facebook is ready to stabilize its development somewhat. When we do that, the commit message should go into detail why we think lfs is better than largefiles, and then probably also add a note to the largefiles help that we think lfs is the way of the future.
> Does that sound like a starting place? Facebook folks, do you think it's a reasonable time to land lfs in core?
David should chime in here, because I haven't really been watching the
LFS side of things. I believe it's being used in production with a
number of users at least, and I haven't heard of any lfs specific
issues, so my guess is it's probably in good shape for upstreaming.
More information about the Mercurial-devel