[PATCH] largefiles: fix support for local largefiles while using share extension

[Henrik Stuart]

On 04-06-2016 04:33, Augie Fackler wrote:
> On Fri, Jun 03, 2016 at 09:55:48AM +0200, Henrik Stuart wrote:
>> # HG changeset patch
>> # User Henrik Stuart <henriks at unity3d.com>
>> # Date 1464938050 -7200
>> #      Fri Jun 03 09:14:10 2016 +0200
>> # Branch stable
>> # Node ID 59465e5e6b059e848e2e127f263288bceaa49015
>> # Parent  e82ca7d0967cd10d92562820297c3413abe6fc29
>> largefiles: fix support for local largefiles while using share extension
>
> I agree this makes sense for stable.
>
>>
>> Prior to revision 2a3f24786d09, largefiles were saved in the local repository,
>> even if it was using the share extension. After that change, all largefiles are
>> now stored in the shared repository. However, the backward compatibility for
>> existing largefiles already placed in the local repository was never tested,
>> and has been broken since.
>>
>> diff --git a/hgext/largefiles/lfutil.py b/hgext/largefiles/lfutil.py
>> --- a/hgext/largefiles/lfutil.py
>> +++ b/hgext/largefiles/lfutil.py
>> @@ -204,7 +204,7 @@
>>      if instore(repo, hash):
>>          return (path, True)
>>      elif repo.shared() and instore(repo, hash, True):
>> -        return storepath(repo, hash, True)
>> +        return storepath(repo, hash, True), True
>>
>>      return (path, False)
>>
>> diff --git a/tests/test-largefiles-shared-repo.t b/tests/test-largefiles-shared-repo.t
>> new file mode 100644
>> --- /dev/null
>> +++ b/tests/test-largefiles-shared-repo.t
>
> However, could this be bolted on to the end of an existing largefiles
> test? That'd let us avoid duplicating a lot of repository setup work.

It could potentially be rolled into test-largefiles-cache like Matt 
suggests in a separate mail, but I rather prefer to keep the interaction 
between largefiles and share in its own test file, building out 
test-largefiles-shared-repo for further scenarios that involve both 
extensions. However, I don't feel strongly about it, and we can easily 
go with Matt's suggestion. Just let me know if I should resend the patch 
with Matt's suggestion instead.

-- 
Kind regards,
   Henrik