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