Mon, 04 Feb 2019 21:14:37 -0800 filemerge: migrate to scmutil.backuppath()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 21:14:37 -0800] rev 41600
filemerge: migrate to scmutil.backuppath() Differential Revision: https://phab.mercurial-scm.org/D5856
Mon, 04 Feb 2019 21:10:17 -0800 mq: migrate to scmutil.backuppath()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 21:10:17 -0800] rev 41599
mq: migrate to scmutil.backuppath() Differential Revision: https://phab.mercurial-scm.org/D5855
Mon, 04 Feb 2019 21:00:58 -0800 largefiles: migrate to scmutil.backuppath()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 21:00:58 -0800] rev 41598
largefiles: migrate to scmutil.backuppath() It seems unnecessary to convert the paths here back to repo-relative paths, but I'll leave that for someone else to clean up. Differential Revision: https://phab.mercurial-scm.org/D5854
Tue, 05 Feb 2019 11:14:07 -0800 revert: migrate to scmutil.backuppath()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 05 Feb 2019 11:14:07 -0800] rev 41597
revert: migrate to scmutil.backuppath() Differential Revision: https://phab.mercurial-scm.org/D5853
Mon, 04 Feb 2019 20:49:45 -0800 shelve: fix broken backup of conflicting untracked file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 20:49:45 -0800] rev 41596
shelve: fix broken backup of conflicting untracked file Differential Revision: https://phab.mercurial-scm.org/D5852
Mon, 04 Feb 2019 20:46:33 -0800 scmutil: introduce a new backuppath() to replace origpath()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 20:46:33 -0800] rev 41595
scmutil: introduce a new backuppath() to replace origpath() Unlike most functions in our codebase, origpath() takes a path that is relative to cwd. This commit introduces a replacement for origpath(). The new function takes a path that is relative to the repo root. There is a lot of duplication between the two, but I intend to remove origpath() within the next few commits, so it won't be a maintenance burden. origpath() is also a little weird in that it returns either a a cwd-relative path or an absolute path. It needs to be able to return a path outside the repo, so it makes sense that it can return an absolute path. However, it would be simpler to always return an absolute path. The new function does that. Differential Revision: https://phab.mercurial-scm.org/D5851
Mon, 04 Feb 2019 09:21:40 -0800 tests: demonstrate broken unshelve when backing up untracked file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 04 Feb 2019 09:21:40 -0800] rev 41594
tests: demonstrate broken unshelve when backing up untracked file Differential Revision: https://phab.mercurial-scm.org/D5850
Wed, 06 Feb 2019 15:35:25 -0800 subrepo: always show relative path to .orig backup
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 Feb 2019 15:35:25 -0800] rev 41593
subrepo: always show relative path to .orig backup Same as previous commit, but for subrepo. Differential Revision: https://phab.mercurial-scm.org/D5873
Wed, 06 Feb 2019 15:26:53 -0800 mq: always show relative path to .orig backup
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 Feb 2019 15:26:53 -0800] rev 41592
mq: always show relative path to .orig backup Same as previous commit, but for mq (I would have folded them, but test-check-commit doesn't like "revert/mq" as a topic and I couldn't think of a better one). Differential Revision: https://phab.mercurial-scm.org/D5872
Wed, 06 Feb 2019 14:57:08 -0800 revert: always show relative path to .orig backup
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 Feb 2019 14:57:08 -0800] rev 41591
revert: always show relative path to .orig backup This helps make some future patches easier when I replace origpath() by another function that works with repo-relative paths (origpath() works with cwd-relative paths). Always showing a relative path seems a little more user-friendly and is more consistent between configured ui.origbackuppath and not. OTOH, it's annoying if ui.origbackuppath is far outside the repo. This is just --verbose output, so I don't think it's worth spending much time on (I've already wasted too many hours on it). Differential Revision: https://phab.mercurial-scm.org/D5871
Tue, 05 Feb 2019 17:02:40 -0500 py3: ensure the HTTP password manager returns strings, not bytes
Matt Harbison <matt_harbison@yahoo.com> [Tue, 05 Feb 2019 17:02:40 -0500] rev 41590
py3: ensure the HTTP password manager returns strings, not bytes The digest handler calls into the password manager on its own, and it apparently expects strings. Perhaps the Basic authentication handler didn't hit this because of its manual password fetch and format in retry_http_basic_auth(). The `pycompat.bytesurl()` on the user and password just above the first url.py diff seems unnecessary, because the password proxy in ui is converting to bytes IIUC.
Tue, 05 Feb 2019 16:47:19 -0500 tests: enable HTTP digest testing
Matt Harbison <matt_harbison@yahoo.com> [Tue, 05 Feb 2019 16:47:19 -0500] rev 41589
tests: enable HTTP digest testing I suppose we could spin the client side extension off to a *.py file if it gets more use. I was basically just looking to avoid killing the server and relaunching it just to change authentication schemes, because that doesn't always work on Windows. The test changes capture the problem with py3.
Tue, 05 Feb 2019 16:16:14 -0500 wsgiheaders: make sure __repr__() returns a string
Matt Harbison <matt_harbison@yahoo.com> [Tue, 05 Feb 2019 16:16:14 -0500] rev 41588
wsgiheaders: make sure __repr__() returns a string When printing `req.headers` on the server side to debug, it complained that '%b' needed to take a string, not bytes. Changing '%s' to '%r' caused it to complain that __repr__ didn't return a string.
Tue, 05 Feb 2019 13:32:39 -0500 tests: add code to handle HTTP digests on the server side
Matt Harbison <matt_harbison@yahoo.com> [Tue, 05 Feb 2019 13:32:39 -0500] rev 41587
tests: add code to handle HTTP digests on the server side It's not hooked up yet. Mostly this was cargoculted and simplified from some python.org code[1]. It's not trying to test the security as much as it is trying to make sure that clients are sending out the right data when challenged. (And they aren't on py3.) [1] http://svn.python.org/projects/sandbox/trunk/digestauth/digestauth.py
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip