[PATCH] largefiles: ignore hidden changesets with 'verify --large --lfa'
pierre-yves.david at ens-lyon.org
Wed Jun 10 18:32:04 CDT 2015
On 06/09/2015 05:55 PM, Matt Harbison wrote:
> 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
>> hg verify runs on an unfiltered repo, it would be consistent to run
>> this one on unfiltered repository too. Why would we want something
>> 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:
> 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).
Sold, pushed to the clowncopter.
More information about the Mercurial-devel