Warning: beware of back references in this email. Plan to read this email twice. I guess I could have reorganized it, but I left Warren Young's text in its original order.
On 10/16/2017 4:28 PM, Warren Young wrote: > On Oct 14, 2017, at 4:16 PM, Andy Goth <andrew.m.g...@gmail.com> 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? On Unix, the existence of the file is 100% the only thing you will see. On Windows, the file not only exists but also can be edited to change which files are and are not symlinks. Use the changes command to immediately see the effects of editing the file, or use the commit command to actually, well, commit. Or use commit -n to dry run creating the new manifest without actually changing the repository. Deleting manifest.symlinks temporarily disables its behavior, and Fossil will fall back on its normal behavior of inheriting the symlink status from the baseline check-in. I say "temporarily" because there are a great many actions that will regenerate manifest.symlinks, along with all the other manifest* files, for example committing. > 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”? I think "fossil up" will blow away edits to manifest.symlinks. That's arguably a bug, and thanks for bringing it to my attention. It would make more sense to preserve edits (or more precisely, the consequence of edits) to manifest.symlinks unless the user is expressly reverting them. > What if the so-named file is already under management? In this case, the file would become a symlink to whatever its content says it's a link to. All that's happening is the "l" permission flag is being added to the manifest. > 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 don't have the luxury of Cygwin because my end users won't have it. It's already like pulling teeth (don't get me started) to get them to allow fossil.exe to be on the install CD even though it itself isn't being installed. It just needs to be there to support read-only browsing of the documentation and the revision history. Adding cygwin1.dll or whatever it's called will totally destroy the already strained relationship I have with them. I do not understand why this is such a massive issue, especially since they refuse to have a rational discussion about their concerns with me, but superstition rules the day. You may be asking why I care about symlinks in the scenario I outlined. It's because I want that same install CD to be useful to the real developers, who should also be able to run the build procedure to get fresh binaries including any changes they may be making. Thanks to the magic of SDX and Starpacks, I was able to sneak the "compiler" onto the CD since it's right inside the repository! > 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. That's a very good start, thanks. I didn't even do Cygwin testing. I only tested using the Windows build procedure drh gave a month or two ago when I asked about it. >> 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. "Reinventing part of Unix, poorly." Haha, you do realize we are talking exclusively about Windows, right? So YES you are correct. Just let me emphasize that I'm not the one doing the reinventing. > 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? You raise an interesting point. An alternative to editing the checkout copy of manifest.symlinks would be defining a new "fossil symlink" command. However, it would have the same effect. In order to work with my application, all "fossil symlink" would do is edit the manifest.symlinks file. Thus I cut out the middleman without even realizing it was there. However, such a command could do more than create and unlink symlinks. Obviously it would specify their target, which would be less error-prone than writing them directly into a file (TRAILING NEWLINE FORBIDDEN). And hey, it could list all the symlinks! I'm certainly not opposed to having such a command to assist with symlink manipulation on Windows. But before you think that having a "fossil symlink" command would 100% obviate manifest.symlinks, another use case I have to deal with is someone working out of a zip file snapshot. The code would still need the list of symlinks, yet since it's just a snapshot from a zip file, there's no Fossil repository and possibly also no Fossil binary. Thus I must have the symlink list show up as a file inside the zip archive. This brings me back to editing the manifest. When working directly on a zip snapshot without Fossil being anywhere nearby, the process for creating a symlink is to edit the symlink list file and to put the target of the link inside the named quasi-symlink file. Fossil has absolutely zero to do with that reality. I'm just making it so that Fossil is capable of recognizing when this is done within a check-in so that the check-in manifest correctly lists which files are symlinks. > 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: I realize I haven't said much about how I'm using symlinks on my actual project. They are predominantly symlinks to large directory trees that have to appear in four or five different places. There are symlinks to individual files, but they are comparatively rare. > 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?) No, the current behavior for native Windows Fossil is to create ordinary files containing the name of their target (no trailing newline). I am preserving exactly that behavior. Even without my change, I believe it is possible on Windows to retarget a symlink by editing that file. Aside from listing the symlinks in the first place (the most important function at the current stage of development of my project), all I'm doing is giving myself the means to create new symlinks in Windows. Otherwise I'd have to go over to Unix to make the symlink, and while I was in the midst of more active development I usually had to make do with whatever computer I happened to be sitting in front of at the moment I discovered that I had work to do. > 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. That licensing update is good to know, but as I said elsewhere in my email, the code is developed and deployed using Tcl Starpacks, and on Windows I prefer to use the standard builds thereof rather than make Cygwin versions. > 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. Admin privileges are the biggest no-go out of anything we've discussed. While this may be a sensible suggestion in other contexts, it's off the table for what I'm doing. > 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. Faking symlinks is exactly what I did all along. From the start, my code was able to treat the Fossil emulation of symlinks just like the real deal. The trick was my code had to know which files to treat as symlinks. My solution to that was to create scripts (runnable only on Unix) that build the symlink list using "find -type l", then check that list into Fossil. It makes a lot more sense to me to simply reuse the information already present in the manifest. > Have I missed any? I could have reworked SDX to not need symlinks in the first place, but in the end it would amount to the same thing. I needed a way to specify that various large subtrees be shared. On Unix, symlinks were exactly the right thing for this, so I seized on it from the very start. When I saw that I would get in trouble in Windows, I implemented #4 above, and it worked very well, except for it being a hassle to make new symlnks. > Why is your way superior to all of these? I'm simply refining option #4. >> 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. I agree that it's confusing, and I started with something else. "s" maybe? I forget. Then I decided to just use the same letter already used in the manifest file to emphasize the relationship between the two. > 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. Mine didn't have "!" (no "1" so where would they put it?) because it's easy enough to type period-backspace-apostrophe. > There must be a better way to enable this: “2”, capital “L”, etc. I think "s" is the best choice if it's not deemed important to use the same letter as the manifest file uses. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
