[PATCH 1 of 4 stable] largefiles: introduce basic debugstate --large functionality

Kevin Bullock kbullock+mercurial at ringworld.org
Fri Dec 21 14:50:54 CST 2012


On Dec 21, 2012, at 2:26 PM, Mads Kiilerich wrote:

> On 12/21/2012 08:10 PM, Kevin Bullock wrote:
>> On Dec 21, 2012, at 12:56 PM, Mads Kiilerich wrote:
>> 
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1356115949 -3600
>>> # Branch stable
>>> # Node ID 7ccb2671617299c81b9ed9f38e3debc7231ebfc4
>>> # Parent  777084ac84167e3bdea45b5c00de1106cca36eef
>>> largefiles: introduce basic debugstate --large functionality
>>> 
>>> Very useful for debugging largefiles "performance" issues.
>> +1 on the general direction.
>> 
>>> The added test exposes an issue that will be solved next.
>> So the test result in the patch is incorrect? Or it's correct but too slow?
> 
> The test result is correct in the way that it shows the current kind-of-working behaviour and the test passes.
> 
> The test result also points out why status currently often is slow.
> 
> - but I guess I just should leave this one out from stable and push the actual status fix on stable without a test and push this test to default.

I'm not sure that's the approach I'd take. It'd be nice if there were _some_ way to expose the issue before the fix lands, and bundle the test to ensure it's fixed into the fix itself.

Maybe you could drive the test using inline Python on stable, and then change it to use 'debugstate --large' on default?

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list