Should bfiles auto-status affect all uses of localrepo.status?

[Anton Markov]

Re-sending with proper line wrapping.

> -----Original Message-----
> From: gerg.ward at gmail.com [mailto:gerg.ward at gmail.com] On Behalf Of
> Greg Ward
> Sent: Thursday, February 18, 2010 10:21 AM
>
> On Wed, Feb 17, 2010 at 5:44 PM, Anton Markov> wrote:
> > Currently, 'hg status' simply pretty-prints the output of the
> > localrepo.status function which is also used by other parts of
> > mercurial. I am trying to decide if I want to (A) alter the
> > output of 'hg status' to include 'hg bfstatus' but leave the output
> > of localrepo.status unchanged, or (B) to change the output of
> > localrepo.status[1].
> > Pros (A): doesn't affect other code, easier to implement
> > Cons (A): the user may get confused if 'hg status' shows a big
>  > file, but
> > another command using localrepo.status ignores that file.
<snip>

Greg Ward:
> On balance, I would say:
>
>   * go ahead and wrap localrepository.status(), since lots of bits of
> Mercurial will *benefit* from modified big files being considered
> modified files

[AM] I agree that localrepo.status() is the proper level to hook in
auto-status integration. Our problem arises from the fact that this
function is used by low-level code in localrepo that should otherwise
be using something simpler.

After looking over the various uses of localrepo.status(), I noticed
that all the problematic cases in Mercurial core (commit, revert,
forget, etc.) are using this function without any revision parameters.
In particular, they get the state of the working copy relative to its
parent. This is just the information stored in the dirstate. The only
advantage of using localrepo.status is that it deals with the files
that dirstate.status is "unsure" about.

This leads me to think there needs to be an internal function (say
'dirstatus') in localrepo that wraps dirstate.status and performs the
hash comparison necessary to figure out the "unsure" cases. This way,
'dirstatus' returns the "concrete" state - that is the state of files
tracked in revlogs, just like the current output of localrepo.status.
On the other hand, 'status' would return the "logical" state which may
include bfiles, subrepositories, and more.

This proposal does require changes to Mercurial core. While we are at
it, I have a few other ideas for a generalized status mechanism that I
will write about in a separate e-mail.

In the meantime, I think we could make auto-status work in extension-
only form with some hacks...

> carefully test the uses that I have flagged as troublesome. #1 is
> localrepo.commit();
 
[AM] Localrepo.commit is the show-stopper for doing a clean
implementation exclusively as an extension. It uses localrepo.status to
grab the lists of added/modified/removed files and uses them to create
changectx and update dirstate. I can't see any clean way to convince it
to ignore these files without copy-pasting localrepo.commit into bfiles
and modifying it as necessary.

I think the cleaner solution would be to wrap localrepo.commit, revert,
remove, and forget, and to revert the behavior of localrepo.status for
the duration of the call.

> We might have to document "do not use bfiles with MQ or record" if
> we have problems there and can't think of a fix.

[AM] I believe that these extensions can be "fixed" in a similar manner
for the short term - that is, by explicitly disabling auto-status for
the troublesome commands. This is probably overkill because the user
will be able to pass --no-bfiles to disable the close integration. It
will also force the user to realize that not all files they see in 'hg
status' will be acted upon by the extensions. Therefore, I would go
with documenting the incompatibility and possibly a warning message if
the extensions are loaded together with bfiles.
 
 
Thanks,

Anton