largefiles + subrepos status problem

Matt Mackall mpm at
Thu Aug 15 15:58:47 CDT 2013

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.

More information about the Mercurial-devel mailing list