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

[Greg Ward]

On Thu, Feb 25, 2010 at 12:00 AM, Anton Markov <anton.markov at gmail.com> wrote:
> 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.

That sounds reasonable.  Perhaps the "concrete" method should be
called _realstatus(): the _ emphasises that it's internal to
localrepository.  Throwing in subrepos as another possible use case is
a good idea.  This could be hard to sell if it's just for bfiles, but
benefiting subrepos too could help.

> 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.

If we end up having some bfiles features require Mercurial 1.6, that's
OK by me.  Not ideal, but tolerable.

> 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.

Cleaner than copy-pasting localrepo.commit(), that's for sure.  Still
a hack!  If it gives us compatibility with 1.3 and up, I suppose it's
worth it.  But if the right thing means refactoring core hg and
requiring hg 1.6 for certain features, so be it.

> [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.

That will get pretty tiresome after about the third command.  ;-)

> 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.

Please let's only show warnings when they matter.  I use MQ on a
bfiles repo regularly, and so far everything is just fine.  (Although
I guess I could just turn off auto-status when I use MQ.)  I should
only get in trouble if I try to create a patch involving a big file.
(Aborting in that case is fine by me.)

Greg