[PATCH RFC] lfs: clean up a variety of strings/bytes issues

Matt Harbison mharbison72 at gmail.com
Sat Jan 26 01:22:01 EST 2019


On Sat, 26 Jan 2019 01:00:03 -0500, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> On Fri, 25 Jan 2019 17:33:54 -0500, Augie Fackler <raf at durin42.com>  
> wrote:
>
>> # HG changeset patch
>> # User Augie Fackler <augie at google.com>
>> # Date 1548455589 18000
>> #      Fri Jan 25 17:33:09 2019 -0500
>> # Node ID d59571aba933f16db8e58ec9b61365ea4db0e2fa
>> # Parent  ffdac0067a147f878ac45dc2c4b3b3e490865252
>> lfs: clean up a variety of strings/bytes issues
>>
>> Mostly these are around json encoding/decoding, which is a hassle for
>> us. After this change there are fewer tracebacks in the lfs tests on
>> Python 3, but I'm very confused by the remaining failures: it looks
>> very much like destrepo.ui.setconfig() in mercurial.hg.clone() isn't
>> working: I can see a repo object with a stable repr() (which includes
>> the object's id) that appears to _lose_ the setconfig()ed
>> paths.default by the time we get into the lfs blobstore setup.
>
> I don't think it is losing `paths.default`.  There's a typo in the  
> followup hacks patch, such that it is looking up 'path.default' (not  
> plural).  I adjusted that, and it prints the path fine in the prompt  
> assertion.
>
> The blobstore is selected during reposetup(), and cached.  A local copy  
> is recreated in the exchange.push() and prefetch() wrappers, which is  
> happening here.  Therefore, the `if not store.has(oid)` in  
> readfromstore() must be busted somehow.

Looking more closely at the debug output, the prefetch request is asking  
to download an empty list of objects.  You can see it if you add `--debug`  
to `hg clone -q http://localhost:$HGPORT $TESTTMP/client3_clone` around  
test-lfs-serve.t:236.  Therefore prefetch is doing nothing, so then it  
wants to call out individually using the original blobstore as the  
filelogs are accessed.


More information about the Mercurial-devel mailing list