Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:52:54 +0900] rev 37570
diffhelpers: naming and whitespace cleanup
Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:51:23 +0900] rev 37569
diffhelpers: remove C implementation in favor of pure Python version
Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:49:39 +0900] rev 37568
patch: stop using cext.diffhelpers
The C implementation has a couple of memory bugs, and lacks error handling
which could lead to SEGV. I could fix them one by one (and I mostly finished
that), but the performance gain provided by cext.diffhelper is quite low.
Besides, diffhelpers.addlines() calls back Python, linereader.readline(),
from the innermost loop.
$ hg export -R mozilla-central 0:100 > patch
$ ls -lh patch
-rw-r--r-- 184M patch
$ hg init repo && hg -R repo import patch --time --bypass
(cext) time: real 34.970 secs (user 32.720+0.000 sys 2.230+0.000)
(pure) time: real 35.950 secs (user 33.600+0.000 sys 2.330+0.000)
So, let's simply use the pure Python implementation.
Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:47:43 +0900] rev 37567
diffhelpers: port docstrings from cext to pure
I'll remove the C implementation.
Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:44:41 +0900] rev 37566
py3: get rid of character access from pure.diffhelpers
's' is a result of readline(), so 'c == "\n"' means 's == "\n"'.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 11 Apr 2018 18:23:29 -0400] rev 37565
lfs: handle paths that don't end with '/' when inferring the blob store
While here, I also checked the lfs.url config directly instead of testing the
scheme, as requested by Yuya.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 08 Apr 2018 14:22:12 -0400] rev 37564
lfs: infer the blob store URL from an explicit push dest or default-push
Unlike pull, the blobs are uploaded within the exchange.push() window, so simply
wrap it and swap in a properly configured remote store. The '_subtoppath' field
shouldn't be available during this window, but give the passed path priority for
clarity.
At one point I hit an AttributeError in one of the convert tests when trying to
save the original remote blobstore when the swap was run unconditionally. I
wrapped it in a util.safehasattr(), but then today I wasn't able to reproduce
it. But now the whole thing is tucked under the requirement guard because
without the requirement, there are no blobs in the repo, even if the extension
is loaded.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 08 Apr 2018 01:23:39 -0400] rev 37563
lfs: infer the blob store URL from an explicit pull source
I don't see any easier way to do this because the update part of `hg pull -u`
happens outside exchange.pull(), and commands.postincoming() doesn't take a
path. So (ab)use the mechanism used by subrepos to redirect where subrepos are
pulled from when an explicit path is given. As a bonus, this should allow lfs
blobs to be pulled into a subrepo when it is checked out.
An explicit push path can be handled within exchange.push(). That can be done
next, outside of this dirty hack.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 11 Apr 2018 17:29:55 -0400] rev 37562
lfs: special case the null:// usercache instead of treating it as a url
The previous code worked on Windows, but not on Unix, and a pending patch's test
failed. The url being used was something like "/tmp/.../client1/null://",
courtesy of ui.configpath(). Looking at the doc comment, this seems like it's
maybe not the right function to call (why should a relative cache path be
expanded relative to the repo root or config file?), but largefiles has been
using it since
8b8dd13295db (Oct 2011). It was introduced in
1b591f9b7fd2 (Jan
2011) without comment or callers. A grep over the whole history shows that only
largefiles used it until lfs and infinitepush came along recently.
It looks like if the `if not os.path.isabs(v) or "://" not in v` in configpath()
is changed to an 'and', both Linux and Windows are happy. I'm guessing that
"://" is to pick off URLs, so that seems reasonable. But I'm not sure why it
isn't explicitly "file://", and I thought that "file://foo" is relative anyway.
(At least, there are doctests for file:///tmp in util.url.) There is no mention
of this setting in the help, but it is referenced on the wiki page for
largefiles. (There's no mention that this is intended to be a URL, and the
example uses an absolute path.)
I don't want this blocking the rest of the lfs server discovery stuff. It was
also wrong to allow a file:// URL here, but not in largefiles.
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 04 Apr 2018 17:37:35 +0530] rev 37561
tests: add tests showing pulling from infinitepush works over wire
The current tests in test-infinitepush-ci.t showed that `hg pull -r <rev>` does
not work. Digging in code, I found that we have logic for pulling from
bundlestore without having client side logic. This patch adds test demonstrating
that pulling from bundlestore works when working over wire.
Pulling from bundlestore when the peer is a localpeer still does not works.
Differential Revision: https://phab.mercurial-scm.org/D3072
Danny Hooper <hooper@google.com> [Fri, 30 Mar 2018 17:01:12 -0700] rev 37560
fix: use a portable python script instead of sed in test
Differential Revision: https://phab.mercurial-scm.org/D2988
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 11 Apr 2018 14:35:37 +0530] rev 37559
py3: use pycompat.bytestr() where repr in involved
Differential Revision: https://phab.mercurial-scm.org/D3244