A Question about bfrefresh

Steve Borho steve at borho.org
Thu Feb 4 08:46:34 CST 2010


On Thu, Feb 4, 2010 at 8:04 AM, Greg Ward <greg-hg at gerg.ca> wrote:
> On Thu, Feb 4, 2010 at 12:25 AM, Steve Borho <steve at borho.org> wrote:
>> Please talk with me about how THG can support bfiles in our status and
>> commit tools before changing repo.status() :)  I'm certain we can find
>> a way to add knowledge of bfiles at or before you monkey-patch the
>> output of the status command.
>
> Hmmm.  I want bfiles to have optional automatic integration with
> 'status' and 'commit', 'update', and 'push' for the benefit of
> command-line users.  I don't want THG users to have any special
> abilities that command-line users don't, e.g. automatic commit of
> modified big files.  (The same goes for any GUI front end that
> supports commit.)
>
> Here's my thinking: if bfiles gets automatic integration right, then
> THG might not need to do much to support bfiles.  Big files look just
> like regular files.  (Except that 'hg status' would print things like
> 'B-M' or 'BPC' for big files.  And that is negotiable: if messing with
> 'status' like that will make lots of people hate me, then I won't do
> it.  There's always the 'bfstatus' command if you need to know which
> big files are pending upload.)

THG does not use the output of commands.status(), we operate at a
lower level, but many tools do (especially IDE integrations).  So any
mods to status output have to be done very carefully, if at all.

> There is one bfiles operation that I do not think can be done
> automatically, which is bfadd.  Everyone has a different idea of what
> constitutes "big" -- I say 100 kB, you say 10 MB.  So I suspect THG
> (and other GUIs!) will need support for adding new big files.  But
> that might be all you need to do, if we get the low-level automatic
> integration right.

That's certainly doable.

The bits that I wonder about are things like patch.diff(); am I going
to be able to query diffs for two arbitrary versions of a big file, or
is this something we should try to avoid?

--
Steve Borho


More information about the Mercurial-devel mailing list