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

Anton Markov anton.markov at gmail.com
Wed Feb 24 23:00:30 CST 2010


Inline below.

> -----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 <anton.markov at gmail.com>
> 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



More information about the Mercurial-devel mailing list