[RFC] kbfiles: an extension to track binary files with less wasted bandwidth

Benjamin Pollack benjamin at bitquabit.com
Sat Oct 1 18:57:25 CDT 2011

On Sep 28, 2011, at 6:04 PM, Greg Ward wrote:

> I have two requests:
>  * [essential] make it possible for largefiles to seamlessly use repos
>    where the standins live in .hgbfiles, so that existing users of
>    bfiles don't have to go through a painful conversion process

I will continue to argue that idea is misguided.

The main point, as we've discussed at length previously, is that it results in bad behavior [1].  To recap: when you push, largefiles looks for largefiles in the changesets you're pushing, asks the server whether it has them already, and uploads any that the server doesn't already have.  It doesn't do any checking for changesets it's not pushing, since, if you're only ever using largefiles, changesets already on the server *must* have their corresponding largefiles.  For the common case I'm envisioning clients doing here--simply setting the largefiles prefix to .bfiles--this precondition is invalid, and you'll trivially be able to make repositories that no one can actually clone.

Especially given that point, I remain unclear why we'd allow changing the largefiles prefix when we don't allow changing the name of .hg/.hgignore/.hgeol and so on.  If, for your particular setup, you *know* that the largefiles preconditions are actually satisfied, and you really don't want to reconvert, it's trivial to add a piggyback extension that swizzles out the standin prefix.  That's what we may do for grandfathering in .kbf standins for existing Kiln clients, for example.  But I really don't believe that behavior should be in core Mercurial.

largefiles is based on bfiles, and owes it a tremendous amount of debt, but they're simply not interchangeable, and I think trying to force them to be is a bad idea. 


[1]: http://selenic.com/pipermail/mercurial-devel/2011-August/033751.html

More information about the Mercurial-devel mailing list