On Oct 14, 2017, at 4:16 PM, Andy Goth <[email protected]> wrote: > > Please review the enhanced-symlink branch.
Aside from a manifest.symlinks file appearing at the project root, what should we see? How do we test it? For example, if I declare a file to be a symlink in the repository by editing that file, what is supposed to happen on “fossil up”? What if the so-named file is already under management? I ask for the benefit of others, not myself, because in the uncommon instances where I run Fossil on Windows, it’s almost always under Cygwin or WSL. In the exceedingly rare exceptions, I use one of the official binaries; I’ve never built a non-Cygwin fossil.exe. I did go ahead and build your branch on Linux and under Cygwin, and all I was able to see is that “fossil set manifest l” caused the manifest.symlinks file to appear, and “fossil unset manifest” made it disappear. > On Windows, this new file can be edited to change which files are and are not > considered to be symlinks. Thus, it becomes possible to create and unlink > symlinks on Windows. If all this branch did is gave Fossil the power to declare where the symlinks are, I’d say it’s probably a harmless change. The fact that manually adjusting the manifest apparently changes Fossil’s behavior worries me. It feels like reinventing part of Unix, poorly. It also feels like reversing a causality arrow: shouldn’t manifests merely declare separately-verifiable facts? You can’t change the contents of a cargo container by rewriting its manifest; why do you call your file a manifest if it doesn’t behave the same way? That in turn begs the question of why you have rejected the other proposed ways of handling symlinks on Windows? Let me see if I can enumerate them all: 1. Just copy files on checkout, and try to do the right thing with changes to “linked” files on checkin. (Is this not the current behavior for native Windows builds?) 2. Use Cygwin or WSL. Fob the headache of how to map semantics off onto those subsystems. You are aware that Red Hat has relicensed Cygwin to avoid the need to buy out the redistribution restriction for executables linked to Cygwin, yes? (https://cygwin.com/licensing.html) Cygwin Fossil symlinks work sanely. 3. Use native NT symlinks. (One of the available branches does this.) This does mean you either require Admin privs or must set the user policy thingamabob that allows normal users to create native symlinks, which is why I rank this lower than the Cygwin/WSL option. 4. Fake symlinks somehow, like Cygwin does in its default mode. (Cygwin’s symlink handling is complex; thus #2. See: https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks) Ranked still lower because it’s reinventing a perfectly good existing wheel. Have I missed any? Why is your way superior to all of these? > If the manifest setting's value is "1" (one) not "l" (ell), the > manifest.symlinks file is disabled. That’s a poor choice of letter, then. It’s inherently confusing. My parents had a mechanical typewriter that didn’t even have a “1” key: you were expected to use the “l” key. I don’t remember if it also lacked a 0 key. There must be a better way to enable this: “2”, capital “L”, etc. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
