[PATCH 06 of 10 stable] largefiles: report localstore errors with single line warnings messages

[Mads Kiilerich]

On 01/28/2013 04:00 AM, Matt Harbison wrote:
> On Fri, 25 Jan 2013 06:17:05 +0100, Mads Kiilerich wrote:
>
>> # HG changeset patch # User Mads Kiilerich <madski at unity3d.com>
>> # Date 1359090896 -3600 # Branch stable # Node ID
>> 7f9af5ed51988a7807d7c15ed559fe4b63c8e880 # Parent
>> 73d88c056d7bb51cc61344395c3c790962f55e07 largefiles: report localstore
>> errors with single line warnings messages
>>
>> The actual hash is also not relevant to report.
>>
>> This makes verify output with multiple failures easier to process.
> ...
>
>> changeset 1:ce8896473775: large1 references missing
>> $TESTTMP/d/.hg/largefiles/5f78770c0e77ba4287ad6ef3071c9bf9c379742f
>> changeset 1:ce8896473775: sub/large2 references corrupted
>> $TESTTMP/d/.hg/largefiles/eb7338044dc27f9bc59b8dd5a246b065ead7a9c4
> +1 for better readability.
>
> This idea might be too much so close to a release because I'm sure there
> are other places, but what would you think of dropping the reference to
> the cached largefile to make it even shorter?

Fine.

I will push this patch to default when it opens again. Please follow up 
with further improvements ;-)

> Given a cset and the normal
> name, you can 'hg cat -r <rev> .hglf/<name>' to get the hash, and
> therefore the .hg/largefiles/<hash> path.  So something like this:
>
>    changeset 1:ce8896473775: large1 is missing
>    changeset 1:ce8896473775: sub/large2 is corrupt
>
> Or are there cases I'm not thinking of where the path may be different,
> and/or be more useful if directly available?  This may be obscure for a
> newbie, but they probably shouldn't be fiddling with the cache directory
> anyway.

Sometimes it is nice to be told where it is looking - whether it is 
using usercache and where it is. I think the full path is relevant when 
reporting corruptions - but probably not in any other cases.

> When cached files are missing, I typically point path.default to a repo I
> know has it and update to that rev.  Or, since verify seems to ignore the
> local files and look to the parent repo's cache (last I checked anyway),

This area probably needs some further work as well.

> point path.default to "" to force verification of the local files.

/Mads