Tue, 26 Dec 2017 22:54:45 +0530 commands: check for empty rev before passing to scmutil.unhidehashlikerevs
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 26 Dec 2017 22:54:45 +0530] rev 35517
commands: check for empty rev before passing to scmutil.unhidehashlikerevs Differential Revision: https://phab.mercurial-scm.org/D1760
Mon, 01 Jan 2018 16:48:31 +0100 test-convert-cvs: change TZ=US/Hawaii to TZ=Pacific/Johnston
Elmar Bartel <elb@leo.org> [Mon, 01 Jan 2018 16:48:31 +0100] rev 35516
test-convert-cvs: change TZ=US/Hawaii to TZ=Pacific/Johnston The former was limited to be known on Linux and the test failed on FreeBSD and Solaris platforms. The newer is known on Linux, FreeBSD and Solaris.
Fri, 29 Dec 2017 23:55:52 -0500 osutil: implement getfsmountpoint() on BSD systems
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 23:55:52 -0500] rev 35515
osutil: implement getfsmountpoint() on BSD systems I don't have a BSD system handy to test this, but it looks simple enough from the man page.
Fri, 29 Dec 2017 23:50:42 -0500 debugfs: display the tested path and mount point of the filesystem, if known
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 23:50:42 -0500] rev 35514
debugfs: display the tested path and mount point of the filesystem, if known While implementing win32.getfstype(), I noticed that MSYS path mangling is getting in the way. Given a path \\host\share\dir: - If strong quoted, hg receives it unchanged, and it works as expected - If double quoted, it converts to \host\share\dir - If unquoted, it converts to \hostsharedir The second and third cases are problematic because those are valid paths relative to the current drive letter, so os.path.realpath() will expand it as such. The net effect is to silently turn a network path test into (typically) a "C:\" test. Additionally, the command hangs after printing out 'symlink: no' for the third case (but is interruptable with Ctrl + C). This path mangling only comes into play because of the command line arguments- it won't affect internally obtained paths. Therefore, the simplest thing to do is to provide feedback on what the command is acting on. I also added the mount point, because Windows supports nesting [1] volumes (see the examples in "Junction Points and Mounted Folders"), and it was a useful diagnostic for figuring out why the wrong filesystem was printed out in the cases above. I opted not to call os.path.realpath() on the path argument, to make it clearer that the mangling isn't being done by Mercurial. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364996(v=vs.85).aspx
Fri, 29 Dec 2017 22:54:14 -0500 util: add a function to show the mount point of the filesystem
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 22:54:14 -0500] rev 35513
util: add a function to show the mount point of the filesystem For now, this is Windows only, since Linux doesn't have the value in its statfs structure, and I don't have a BSD system to test with.
Fri, 29 Dec 2017 22:15:37 -0500 win32: split a utility function to obtain the volume out of getfstype()
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 22:15:37 -0500] rev 35512
win32: split a utility function to obtain the volume out of getfstype() This is only done on Windows because it's simple enough to call statfs() on Unix. The goal is to display this in `hg debugfs`.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip