largefiles + subrepos status problem

[Matt Harbison]

I'd like to isolate this a bit better before writing up a bug...

I have a largefiles repo and subrepo at work, and the subrepo has a few 
more commits on top of the last one committed in the parent.  I didn't 
realize this, and so when I tried to update to another named branch in 
the parent, it rightfully complained about crossing branches.  However, 
when I ran 'hg st -S' from the parent, it only printed the untracked 
files.  (I don't have the repo here, but I believe 'summary' properly 
noticed the extra subrepo commits weren't locked into the parent.)  Thg 
noticed that the subrepo was changed, so they must have custom code to 
handle that.

I tried 2.6.3, 2.7, 2.6, 2.5 and 2.4 to no avail, before going back to 
2.7 again.  I know the status code in largefiles is hairy, so I deleted 
the 'largefiles' line in the 'requires' file, disabled the largefiles 
extension on the command line, and status then printed out the expected 
files and states correctly (only normal files were modified and renamed 
in these extra commits).  I'm not having the problem on RHEL 5.4 with a 
clone of that setup, so I cloned the problematic repo on the same 
machine with the problem (Windows 7, 32 bit), and that clone does not 
have a problem either.

So I'm a bit stumped- it's pretty clearly something largefiles isn't 
getting right, but also specific to that repo/working copy.  The 
problematic repo has a bunch of object files and build junk that is 
ignored, and a handful of untracked files, but I'm not sure that would 
cause a problem.  I know some status related stuff is cached, but I 
would think an 'update -C' would clobber all of that if something is 
bad, yet the problem remains.  I added a --traceback just in case, but 
nothing was reported.

Any tips for debugging this on Monday?  I can't spend a lot of time on 
it, but I don't want to ignore it in case the problem goes away somehow.

--Matt