Mon, 09 Apr 2018 20:52:54 +0900 diffhelpers: naming and whitespace cleanup
Yuya Nishihara <yuya@tcha.org> [Mon, 09 Apr 2018 20:52:54 +0900] rev 37570
diffhelpers: naming and whitespace cleanup
Mon, 09 Apr 2018 20:51:23 +0900 diffhelpers: remove C implementation in favor of pure Python version
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
Mon, 09 Apr 2018 20:49:39 +0900 patch: stop using cext.diffhelpers
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.
Mon, 09 Apr 2018 20:47:43 +0900 diffhelpers: port docstrings from cext to pure
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.
Mon, 09 Apr 2018 20:44:41 +0900 py3: get rid of character access from pure.diffhelpers
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"'.
Wed, 11 Apr 2018 18:23:29 -0400 lfs: handle paths that don't end with '/' when inferring the blob store
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.
Sun, 08 Apr 2018 14:22:12 -0400 lfs: infer the blob store URL from an explicit push dest or default-push
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.
Sun, 08 Apr 2018 01:23:39 -0400 lfs: infer the blob store URL from an explicit pull source
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.
Wed, 11 Apr 2018 17:29:55 -0400 lfs: special case the null:// usercache instead of treating it as a url
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.
Wed, 04 Apr 2018 17:37:35 +0530 tests: add tests showing pulling from infinitepush works over wire
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip