Interoperability of largefiles/bfiles

Greg Ward greg at
Sat Oct 22 15:12:11 CDT 2011

Hi Benjamin --

back on Oct 2, I suggested (and Matt endorsed) this idea:

>   if '.hglf/' is a dir:
>     use that as the largefiles standin prefix
>   elif '.hgbfiles' is a dir:
>     use that as the largefiles standin prefix
>   elif '.kbf' is a dir:
>     use that as the largefiles standin prefix
>   else:
>     no largefiles in this changeset: fallback to 'hglf' in case
>     someone adds one

and a few days later, you bravely volunteered:

> All right.  I'll submit a patch with this logic.

I spent some time last weekend doing the preparatory refactoring. I
don't think we're gonna make it in time for 2.0. Even if we do, the
size of that refactoring patch is enough for Matt to reject it during
code freeze. Darn. (Unless you thought up a really clever,
non-invasive way of doing it. My approach was to turn the global
constant 'shortname' in into a class attribute of
largefiles_repo. That seems promising, but it took me a whole day just
to do that refactoring, which is an indication of its invasiveness.)

I remain hopeful that we can pull this off for 2.1.

So here's my backup plan:

  * create a named branch 'migration' of bfiles
  * shrink all of bfiles down to a tiny little ~10-line extension that
    changes lfutil.shortname to '.hgbfiles'
  * see if it works
  * write something to migrate bfiles stores to largefiles
  * write some docs, also committed on that 'migration' branch of bfiles

The catch: having bfiles and largefiles enabled at the same time could
be weird. Any new largefiles repo will put standins in .hgbfiles,
which is wrong.

Let me know if I'm missing anything and/or you have a better idea.
(E.g. what are you guys doing to kbfiles? I assume something like the
above, minus the store conversion script.)


More information about the Mercurial-devel mailing list