Completely baffled

[Mads Kiilerich]

On 12/05/2011 06:59 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: mercurial-bounces at selenic.com [mailto:mercurial-
>>
>> 2011/12/5 Liam Routt<liam.routt at mediasaints.com>
>>
>>> 	Just as a followup, we managed to lose the last two days of work
>>> by one of our developers today with Mercurial, which really hurts.
>>
>> My team uses Largefiles heavily and we have not seen this.  Are you
>
> I think I was able to reproduce this, here's a minimal set of commands that causes the modified large file to no longer be modified:

Yes, there is a bug here. A simpler test case:

   $ hg init foo
   $ cd foo
   $ echo "[extensions]" >> .hg/hgrc
   $ echo "largefiles=" >> .hg/hgrc

   $ touch thisfileislarge normal
   $ hg add --large thisfileislarge
   $ hg add normal
   $ hg commit -m0

   $ hg tag t

   $ hg up -qr 0

   $ echo BLUE > thisfileislarge
   $ echo blue > normal
   $ hg stat
   M normal
   M thisfileislarge

   $ hg up
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   getting changed largefiles
   0 largefiles updated, 0 removed

   $ hg stat # should also show 'M thisfileislarge'
   M normal
   $ cat thisfileislarge
   BLUE

The problem seems to be related to the synchronization between the 
working directory, the old standin in .hglf and the (potentially) new 
standin.

The test behaviour is not stable - run the tests several times before 
you trust the output.

It was unreliable behaviour like this that tricked me into introducing a 
stupid test in e89385e4ef8d.

I think something fishy is going on with all the invocations of 
lfdirstate.normal (for example in openlfdirstate) and how we can't mark 
a file as normal within the second it was updated, but I haven't figured 
out what the intention with the code is and I thus can't tell if it 
works correctly.

/Mads