-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
working_copy: implement symlinks on Windows with a helper function #2939
Conversation
Alright, we've got some test failures on windows-latest. They pass locally, but presumably the runner is not in developer mode and doesn't run as admin - Windows only supports symlinks if one of those things is true! I'll look into modifying the tests, which were previously #[cfg(unix)], so that they look for either success or a special "this Windows instance does not support this feature" error. In order to achieve that I'll probably make the symlink function the same on both windows and unix, instead of just having the same name. That way we can get better error messages at runtime when this failure occurs on unconfigured-for-symlinks machines. |
The exact requirements for symlinks appear to be:
|
bbc712b
to
bbd9254
Compare
The test changes were more invasive than I hoped and so I've split them into an extra commit. This has some nasty nested error handling, and probably needs a restructure, but I don't know what patterns we prefer for this sort of thing - feedback appreciated! |
bbd9254
to
57c8fcb
Compare
Optionally, it would be nice to update You could say:
It might also be worth adding that, for colocated repos to work, the git option must be set. (Again, this can go in separately if it's a chore) |
1509ee3
to
7f06842
Compare
I've updated those docs, and addressed (I think!) the requested changes. |
The main goal is to avoid having a symlink in our source tree. Currently, there is no good way to work with the `jj` repo with `jj` on Windows. Currently `jj` just crashes with symlinks. This is being worked on, see e.g. martinvonz#2939, but it will always depend on whether Developer Mode is enabled in Windows or whether symlinks are materialized as text files with symlinks. Finally, MkDocs has trouble following symlinks on Windows, so building docs wouldn't work there. Another advantage is that, previously, we were lucky that MkDocs treats `insta` header in `cli-reference@.md.snap` as a Markdown header and follows symlinks at all. Now, we no longer depend on that.
The main goal is to avoid having a symlink in our source tree. Currently, there is no good way to work with the `jj` repo with `jj` on Windows. Currently `jj` just crashes with symlinks. This is being worked on, see e.g. martinvonz#2939, but it will always depend on whether Developer Mode is enabled in Windows or whether symlinks are materialized as text files with symlinks. Finally, MkDocs has trouble following symlinks on Windows, so building docs wouldn't work there. Another advantage is that, previously, we were lucky that MkDocs treats `insta` header in `cli-reference@.md.snap` as a Markdown header and follows symlinks at all. Now, we no longer depend on that.
The main goal is to avoid having a symlink in our source tree. Currently, there is no good way to work with the `jj` repo with `jj` on Windows. Currently `jj` just crashes with symlinks. This is being worked on, see e.g. #2939, but it will always depend on whether Developer Mode is enabled in Windows or whether symlinks are materialized as text files with symlinks. Finally, MkDocs has trouble following symlinks on Windows, so building docs wouldn't work there. Another advantage is that, previously, we were lucky that MkDocs treats `insta` header in `cli-reference@.md.snap` as a Markdown header and follows symlinks at all. Now, we no longer depend on that.
b18047d
to
1dfff8a
Compare
I've modified the previous approach based on Martin's patch to create regular files on unsupported platforms. The supportness check goes from a cfg to a flag stored in the TreeState - always true on unix, true on windows if Developer Mode is enabled; turns out we can check that by looking in the registry. The symlink tests are now enabled on all platforms. I've also addressed the other feedback, with the possible exception of the concern in #2939 (comment) - @yuja may want to weigh in. |
b3668be
to
55e87b2
Compare
I think that's everything for now. |
55e87b2
to
f725e8a
Compare
Addressed feedback and rebased. |
f725e8a
to
98fea9a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks.
enables symlink tests on windows, ignoring failures due to disabled developer mode, and updates windows.md
98fea9a
to
474a792
Compare
Fixes #2
Checklist
If applicable:
CHANGELOG.md