largefiles + subrepos status problem

[Matt Mackall]

On Fri, 2013-08-09 at 23:05 -0400, Matt Harbison wrote:
> 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.

I'd put about 90% odds on largefiles being unaware/insufficiently aware
of subrepos. You tend to find lots of bugs at the intersection of niche
features like this.

-- 
Mathematics is the supreme nostalgia of our time.