Question about auto-refresh and detecting manual edits to standins

[Greg Ward]

[Tessa Starkey]
>  I'm a part of the group of students working on improvements to bfiles.
> Recently we were discussing how to detect manual modifications of the bfile
> stand-in files and a question arose.
> (Issue link: https://ucosp.fogbugz.com/default.asp?36#450)

First, I'm not convinced there is a problem here that needs solving.
We've been using bfiles in production for a couple of weeks now, and
on one or two occasions I had to manually modify a standin.  I think
this was merge-related: since bfiles currently has no support for
merging, you just end up merging the standins.  It all works fine, but
you could trash your merge with a badly timed bfrefresh command.

If someone deliberately modifies a standin, I would give them the
benefit of the doubt and assume that they know what they are doing.
We could issue a warning, but I would be leery of anything more than
that.

[Anton Markov]
> There are three main pieces of state associated with a bfile:
>  1. The placeholder file in the repository (PR)
>  2. The placeholder file in the working directory (PW)
>  3. The bfile in the working directory (BW)

The terminology is *standin*, please.  There is no such thing as a
"placeholder" in bfiles.

Also, there is more state in .hg/bfiles/current, .hg/bfiles/pending,
and .hg/bfiles/latest.  It's already very tricky to keep all these
things straight in my head, so let's be very very *very* careful about
adding more state.

> Consider these VALID scenarios:
>  1. In a clean working copy, we have (PR = PW = BW). That is, the
> placeholder is unmodified and its hash matches the bfile.
>
>  2. If a user modifies the bfile, then (PR = PW != BW)
>
>  3. After an 'hg bfrefresh', we end up with (PR != PW = BW)
>
>  4. If the user subsequently modifies the bfile we get (PR != PW != BW)
>
>  5. Finally, the user copies in the original version of the bfile from
> elsewhere and so (PR != PW != BW = PR)

Another valid scenario:
  - update to 1.0-branch
  - modify a big file
  - bfrefresh and commit
  - update to default
  - merge from 1.0-branch

At this point your working copy contains modifications in .hgbfiles/
that happened behind bfiles' back ... and that is *totally OK*.  (Yes,
bfiles should probably grow some support for merging at some point,
but it's not a high priority.)

I need to hear some use cases explaining *why* we care about
back-channel modifications in .hgbfiles/.

Greg