Completely baffled

[Christian Ebert]

* Mads Kiilerich on Monday, December 05, 2011 at 20:34:16 +0100
> 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.

http://selenic.com/hg/rev/77325c92db95
might be interesting in this context - without the sleep call
testing dirstate.normal was not reliable.

c
-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions