[PATCH 02 of 10 stable] largefiles: adopt verify to batched remote statlfile (issue3780)

Kevin Bullock kbullock+mercurial at ringworld.org
Mon Jan 28 11:47:53 CST 2013


On Jan 28, 2013, at 7:50 AM, Mads Kiilerich wrote:

> On 01/27/2013 05:25 PM, Kevin Bullock wrote:
>> On 24 Jan 2013, at 11:17 PM, Mads Kiilerich wrote:
>> 
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1359090858 -3600
>>> # Branch stable
>>> # Node ID d956326990d42e04627d0d8077380c6f69921132
>>> # Parent  4ac7648ee50c5a799fec5cd2c48d89b99b6dd044
>>> largefiles: adopt verify to batched remote statlfile (issue3780)
>>> 
>>> 9e1616307c4c introduced batching of statlfile, but not all codepaths got
>>> converted.
>>> 
>>> 'hg verify' with a remotestore could thus crash with
>>>  TypeError: 'builtin_function_or_method' object is not iterable
>>> 
>>> Also, the 'hash' variable was used without assigning to it. Don't use variable
>>> names that collide with Python built-in functions. Instead we use 'expecthash'
>>> as in localstore.
>>> 
>>> diff --git a/hgext/largefiles/remotestore.py b/hgext/largefiles/remotestore.py
>>> --- a/hgext/largefiles/remotestore.py
>>> +++ b/hgext/largefiles/remotestore.py
>>> @@ -87,7 +87,8 @@
>>> 
>>>         verified.add(key)
>>> 
>>> -        stat = self._stat(hash)
>>> +        expecthash = fctx.data()[0:40]
>>> +        stat = self._stat([expecthash])[expecthash]
>> Hmm, this call pattern starts to seem like a code smell.
>> 
>> 1. Should we provide a _statfile(hash) to verify just one file like used to be possible?
>> 
>> 2. Alternatively, are we defeating batching here on purpose? Should this be refactored to enable batching?
> 
> Yes, it smells. But it is no longer dead - it just smells funny.
> 
> For a stable fix I prefer to make a minimal change and duplicate existing patterns - this and a lot of other things should be cleaned up later.

Yeah, that's okay by me. I just don't want to lose track of it after the release.

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



More information about the Mercurial-devel mailing list