A Question about bfrefresh

[Steve Borho]

On Wed, Feb 3, 2010 at 9:33 PM, Greg Ward <greg-hg at gerg.ca> wrote:
> On Wed, Feb 3, 2010 at 10:15 PM, Qi Yang <qi.yang137 at gmail.com> wrote:
>> This is Wendy from UCOSP group. I’m currently looking at bfiles extension
>> and trying to do autorefresh (https://ucosp.fogbugz.com/default.asp?33#378)
>> . I noticed that for each bfput or commit we need to do bfrefresh first. My
>> question is why we need separate this bfrefresh method?  Is there other
>> issues other than the speed problem?
>
> Actually, performance didn't really enter into it.  bfrefresh is a
> separate step because it seems evil for hg to implicitly modify
> version-controlled files for you right before committing them.  That
> is, if you run "hg status" and see
>
>  M foo
>  A bar
>
> you expect your next changeset to affect two files: foo and bar.  If
> it actually does
>
>  M foo
>  M .hgbfiles/bigfile
>  A bar
>
> then that would be a little surprising.  Perhaps even evil.  ;-)
>
> My goal with the *basic* layer of bfiles was for everything to be
> clear, explicit, and in the user's hands.  bfrefresh is part of that
> (as is bfadd and bfstatus).
>
> The next move is of course tighter integration with core hg, which
> means doing exactly what I just said is surprising or even evil.  But
> it would be much less surprising if "hg status" actually reports
>
>  M foo
>  A
>  B-M bigfile
>
> before "hg commit" magically updates .hgbfiles/bigfile.

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.

There's a lot of interest in TortoiseHg having first rate support of bfiles.

Cheers.

--
Steve Borho