Question about auto-refresh and detecting manual edits to standins

[Qi Yang]

Hi, Greg:

Could you please give an example of the senario: "you could trash your merge
with a badly timed bfrefresh command." ?

Thanks,
Wendy

On Tue, Feb 9, 2010 at 5:54 PM, Greg Ward <greg-hg at gerg.ca> wrote:

> [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100209/0d9c11aa/attachment.htm>