A Question about bfrefresh

Greg Ward greg-hg at gerg.ca
Wed Feb 3 21:33:32 CST 2010


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.

In other words, auto-status mode is approximately as important as
auto-refresh mode.  I think they are both essential, I'm just not sure
if one must come before the other.  Offhand I think that auto-status
mode should come first.

Greg


More information about the Mercurial-devel mailing list