RFC: version (big) file snapshots with storage outside a Mercurial repo with snap

Dirkjan Ochtman dirkjan at ochtman.nl
Thu Aug 19 10:06:16 UTC 2010


On Mon, Aug 16, 2010 at 21:10, Klaus Koch <kuk42 at gmx.net> wrote:
> The main difference really is the architecture and the IMHO more
> transparent use and development.
>
> Another difference is the 'attitude'.  As far as I understood, for
> Greg it was important to control explicitly what files are checked in
> as big files.  In my company, we have many users who want to use the
> same command for checking in a file.  (It seems, you can now configure
> the Mercurial commands to execute the bfiles commands like bfadd,
> bfrefresh, bfput etc.)  None of the 'attitudes' is more right than the
> other, but for me it was important that it is impossible by default to
> accidentally commit files with compressed deltas bigger than
> Mercurial's limit of 4GiB.  (Actually, snap sets the hard limit to
> 750000000 Bytes as this is the effective limit for 32 bit systems
> regarding free memory address space.)
>
> The different 'attitude' shows also in the way the commands behave.
> An 'hg status' will print the usual states and files.  There is no
> 'B-M' etc. status.  If one wants to see the status of all (to be)
> snapped files, one can use 'hg status --snapped' to print only those.
>
> The code of snap is in some way a blue print of what one would need to
> add where in Mercurial's core to handle big files.  I tried hard to
> avoid reimplementing Mercurial functionality, and searched instead for
> the single point where the smallest change added support for
> snapped/big files.

Okay, but it seems you did not publish your concerns about bfiles'
approach before embarking on coding your own, correct?

You may dismiss Adrian's concerns about code size as FUD, but it would
seriously have helped your case if there was a public conversation
between you and Greg and Andrei about design for these features. Now,
we just have your big wad of code (written by just you in five days)
and their big wad of code (written by a bunch of people over the
course of a few months, and in actual use at several companies IIUC).

I'd hoped Greg Ward would comment here about his thoughts on your
extension, but he hasn't done so yet. Anyway, it would be more
productive IMO if you talked to him about moving bfiles in the
direction you want (or snap in the direction of things he needs,
though I doubt that would be the more productive approach). That way,
we might actually converge on an extension that works for most people
and thus at some point something we could support in hgext.

Cheers,

Dirkjan



More information about the Mercurial-devel mailing list