Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 23:55:52 -0500] rev 35519
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.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 23:50:42 -0500] rev 35518
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
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 22:54:14 -0500] rev 35517
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.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 22:15:37 -0500] rev 35516
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`.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 30 Dec 2017 21:15:12 -0500] rev 35515
util: whitelist NTFS for hardlink creation (issue4580)
Matt Harbison <matt_harbison@yahoo.com> [Fri, 29 Dec 2017 21:28:19 -0500] rev 35514
win32: implement util.getfstype()
This will allow NTFS to be added to the hardlink whitelist, and resume creating
hardlinks in transactions (which was disabled globally in 07a92bbd02e5; see also
e5ce49a30146). I opted to report "cifs" for remote volumes because this shows
in `hg debugfs`, which also reports that hardlinks are supported for these
volumes. So being able to distinguish it from "unknown" seems useful.
The documentation [1] seems to indicate that SMB isn't supported by these
functions, but experimenting shows that mapped drives are reported as "NTFS" on
Windows 7. I don't have a second Windows machine, but instead shared a temp
directory on C:\. In this setup, both of the following were detected as 'cifs'
with the explicit GetDriveType() check:
Z:\repo>hg ci -A
C:\>hg -R \\hostname\temp\repo ci -A # (without Z:\ being mapped)
It looks like this is called 6 times to add and commit a single new file, so I'm
a little surprised this isn't cached.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx
Matt Harbison <matt_harbison@yahoo.com> [Sat, 30 Dec 2017 21:07:03 -0500] rev 35513
util: move getfstype() to the platform modules
This makes room for implementing on Windows using ctypes.
Anton Shestakov <av6@dwimlabs.net> [Fri, 22 Dec 2017 23:17:04 +0800] rev 35512
graphlog: add another graph node type, unstable, using character "*" (BC)
Matt Harbison <matt_harbison@yahoo.com> [Tue, 26 Dec 2017 23:40:49 -0500] rev 35511
largefiles: modernize how capabilities are added to the wire protocol
See 982f13bef503, which came well after this code was originally written.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 23 Dec 2017 17:49:12 -0500] rev 35510
lfs: show a friendly message when pushing lfs to a server without lfs enabled
Upfront disclaimer: I don't know anything about the wire protocol, and this was
pretty much cargo-culted from largefiles, and then clonebundles, since it seems
more modern. I was surprised that exchange.push() will ensure all of the proper
requirements when exchanging between two local repos, but doesn't care when one
is remote.
All this new capability marker does is inform the client that the extension is
enabled remotely. It may or may not contain commits with external blobs.
Open issues:
- largefiles uses 'largefiles=serve' for its capability. Someday I hope to
be able to push lfs blobs to an `hg serve` instance. That will probably
require a distinct capability. Should it change to '=serve' then? Or just
add an 'lfs-serve' capability then?
- The flip side of this is more complicated. It looks like largefiles adds an
'lheads' command for the client to signal to the server that the extension
is loaded. That is then converted to 'heads' and sent through the normal
wire protocol plumbing. A client using the 'heads' command directly is
kicked out with a message indicating that the largefiles extension must be
loaded. We could do similar with 'lfsheads', but then a repo with both
largefiles and lfs blobs can't be pushed over the wire. Hopefully somebody
with more wire protocol experience can think of something else. I see
'x-hgarg-1' on some commands in the tests, but not on heads, and didn't dig
any further.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 24 Dec 2017 01:26:36 -0500] rev 35509
lfs: allow non-lfs exchanges when the extension is only enabled on one side
Once the 'lfs' requirement is added, the extension must be loaded on both sides,
and changegroup3 used. But there's no reason that I can see for bailing with
cryptic errors if lfs is not required, but randomly enabled somewhere.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 23 Dec 2017 23:51:40 -0500] rev 35508
lfs: add the 'lfs' requirement in the changegroup transaction introducing lfs
A hook like this is how largefiles manages to do the same. Largefiles uses a
changegroup hook, but this uses pretxnchangegroup because that actually causes
the transaction to rollback in the unlikely event that writing the requirements
out fails. Sadly, the requires file itself isn't rolled back if a subsequent
hook fails, but that seems trivial.
Now that commit, changegroup and convert are covered, I don't think there's any
way to get an lfs repo without the requirement.
The grep exit code is blotted out of some test-lfs-serve.t tests now showing the
requirement, because run-tests.py doesn't support conditionalizing the exit
code.