[PATCH] largefiles: ignore hidden changesets with 'verify --large --lfa'

[Matt Harbison]

On Tue, 09 Jun 2015 14:04:48 -0400, Pierre-Yves David  
<pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 06/08/2015 07:55 PM, Matt Harbison wrote:
>> On Mon, 08 Jun 2015 22:16:20 -0400, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>>
>>>
>>> On 06/08/2015 05:52 PM, Matt Harbison wrote:
>>>> # HG changeset patch
>>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>>> # Date 1433643018 14400
>>>> #      Sat Jun 06 22:10:18 2015 -0400
>>>> # Node ID 7beb2d6c7bf755f83293e9780b82a2632fc2918a
>>>> # Parent  378a8e700e02794e991d3521423a4f581b635666
>>>> largefiles: ignore hidden changesets with 'verify --large --lfa'
>>>>
>>>> Previously, if there were any hidden changesets, the --lfa argument
>>>> would cause
>>>> the command to abort with a hint about using --hidden when it tripped
>>>> over a
>>>> hidden changeset.
>>>
>>> do you want operation on an unfiltered repository instead?
>>
>> I thought about it, but I guess there's the potential for a largefile to
>> be amended, and the original cset hidden.  So why bother verifying the
>> hidden file if --hidden isn't specified?  It seems that this way, both
>> visible and visible + --hidden are possible, depending on what the user
>> wants.
>
> hg verify runs on an unfiltered repo, it would be consistent to run this  
> one on unfiltered repository too. Why would we want something different?
>
> What does --lfa and --large argument do exactly?

--large is actually implied by --lfa, so ignore that (it used to not be).

--lfa means "verify all largefiles", instead of verifying only the  
largefiles in rev '.'.

"Verification" is simply looking for each '.hglf/foo', and whatever hash  
it contains, make sure there is a matching file in the store.  With --lfc,  
it will then hash the file it finds, to make sure it matches its file name  
(i.e., the store file wasn't corrupted).

I'm _guessing_ that normal verify operates even on hidden csets due to the  
sequential nature of revlog, so you almost have to?  Aside from not  
wanting to waste time verifying largefile content that has been amended  
away, there's this that I just remembered:

http://bz.selenic.com/show_bug.cgi?id=4242

Basically, if there's a --config paths.default, verify makes sure that the  
largefiles are on the server store, instead of checking the local store.   
Clearly, a largefile that is amended won't be pushed to the server, so the  
verify will fail if we use an unfiltered repo and there's a path.  (For  
the record, I agree with the bug report that the behavior is wrong by  
default, but it helped me just last week, so I don't want to get rid of it  
completely).