Auto-refresh proposal

[Benjamin Pollack]

On Feb 18, 2010, at 9:25 AM, Greg Ward wrote:

> Now, at first blush, I am inclined to say that in both cases the
> standin file should take precedence over the big file in the working
> dir.  But that risks losing the user's work.  Consider:
> 
>  * user modifies bigfile
>  * user runs "hg update X" where X is a changeset with a different
> revision of bigfile
>  * user runs "hg bfupdate": if bfupdate gives the standin (modified
> by "hg update") precedence, it will trash the user's modification to
> bigfile: not good

It seems like the fix for this is trivial:

  1. If the standin AND the bigfile AND bfile's dirstate is clean,
     update.
  2. Otherwise, abort updating, and demand the user commit or revert
     to resolve the situation.

We can't really merge bigfiles by definition, so the normal "hg up" behavior seems like a bad idea.  Aborting seems like a reasonable alternative, and has the benefit of working with or without autoupdate equally well.

> The good news is that there is already so much state in .hg/bfiles
> that it might be possible to do a reliable "is it changed?" check
> without adding any more state.  The bad news is that it requires
> reading the content of the file to compute the hash.

That seems totally reasonable to me.  You're about to update, which can be a slow operation anyway when you're just merging and overwriting text files.  Taking a second to SHA-1 a few things doesn't seem like a big deal, and would let Wendy reuse the existing machinery in bfiles, as you point out.

>> 2.        Easier to detect when standin is modified by user
>> 
>>     * There has been a lot of discussion about how to detect this problem
>> (http://selenic.com/pipermail/mercurial-devel/2010-February/018539.html) if
>> we this proposal is possible, we could simplify this problem and solve it as
>> solution in scenario b.
> 
> I'm still not convinced this is a problem.  Yes, we need to do
> something about corrupt standins.  (E.g. user forgets to resolve a
> merge conflict and leaves a file with "<<<<" markers.)  But if I put a
> valid SHA-1 hash in a standin that refers to a revision that already
> exists somewhere (e.g. in .hg/bfiles/pending, .hg/bfiles/committed, or
> the central store), then that should be accepted.

I also completely agree.  As long as it's a valid SHA-1, and as long as one of those three places has a corresponding file, I think it should be valid.  That also has the benefit of making it much, much easier to quickly `hg revert` a file to an earlier revision, even if you don't have fast network access to the central store when you're doing it--something that'd be really important to me when I was hacking on the road.

--Benjamin