Interoperability of largefiles/bfiles

Andrew Pritchard awpritchard at gmail.com
Sat Oct 22 19:50:45 CDT 2011


I might point out that the first approach you described is exactly
what I did to let the version of largefiles Fog Creek is shipping with
Kiln until Mercurial 2.0 is released work with '.kbf' standin
directories.  I maintained it as essentially two diverging forks off
of a single repository.  The relevant one is at
https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles-kiln.
migration.py contains the code that checks for the standin directory
location, along with some other upgrade-checks (like adding
'largefiles' to .hg/requires or replacing 'kilnbfiles' with
'largefiles') that should be superfluous by now since largefiles has
been shipped with Kiln's auto-updating extensions for a while.

The extent of the changes, if I recall correctly, was adding a repo
argument to most of the standin-related functions in lfutil.py and
performing the checks in reposetup.py.

On Sat, Oct 22, 2011 at 3:12 PM, Greg Ward <greg at gerg.ca> wrote:
> 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 lfutil.py 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.)
>
> Greg
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>


More information about the Mercurial-devel mailing list