Upstreaming Facebook extensions
raf at durin42.com
Tue Nov 14 11:26:55 EST 2017
> 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?
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel