[PATCH RFC] lfs: clean up a variety of strings/bytes issues
Matt Harbison
mharbison72 at gmail.com
Sat Jan 26 06:22:01 UTC 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