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

[Greg Ward]

[me]
>> 6) It would be nice to make migration from bfiles painless and transparent.
>>   My first suggestion: make the '.hglf' prefix configurable. Then bfiles
>>   users can just set it to .hgbfiles and not have to go through a painful
>>   repository conversion just to remap the standin filenames.
>

[Andrew Pritchard]
> The problem with a configurable prefix is that it makes a huge mess
> out of interaction between clients and servers, in that clients and
> servers would both have to agree on the prefix; if they didn't, all
> sorts of crazy and confusing things could happen.

Eek. So I'd have to make damn sure to configure largefiles the same on
all clients and servers. Luckily, I have the ability to do that! (I
wrote an extension that gives me central control over all of my
developers' .hg/hgrc files. I try not to let the power go to my head.)

(For "I" read "anyone wanting to migrate transparently from bfiles to
largefiles".)

Idea: how hard would it be to add the standin prefix dir to the wire
protocol? It should only have to be sent once per conversation.

> If you really want to use your bfiles repositories as-is,
> it's easy to write a several-line extension that just sets
> lfutil.shortname in extsetup(ui)

True enough. But then I have to make sure that extension is installed
and enabled on all client and server machines, which is approximately
as difficult as making sure largefiles is configured the same
everywhere. To me, it seems easier to make largefiles configurable
(or, as MPM suggested, adaptable).

> but I'm planning on adding a
> conversion script anyway (I think it's likely to be nothing more than
> a filemap for the convert extension).

Yeah, that should be easy. *But* it's not a transparent migration,
since all of our changeset IDs would change. We have thousands of
Bugzilla slips that link to changesets in hgweb. Who's going to
migrate them?

Greg