On Nov 2, 2015 9:32 AM, "Eric Rubin-Smith" <eas....@gmail.com> wrote: > > >>>> My problem is not the decision itself, but that, in terms of how fossil should behave, it's a philosophical question. Those have no right/wrong answer, and i dislike seeing software pretend to know the answer to such questions. >>> >>> >>> Isn't that essentially confirming my point? Fossil merely stores the pointer. It need not waste time analysing the link to make a judgement call in any way. Just store it and move on. >> >> >> But if it only stores a pointer, and requires the user to reconstruct the link, it's not terribly useful/friendly. The user would potentially have to replace fossil's placeholder pseudosymlink file with a link of his own (which he could point somewhere else than fossil thinks it "should" be). He might has well simply have a "post-checkout" script which sets up his symlinks for him. To me, that's the "proper"/"safest" way to handle symlinks in a repo (but i'm willing to accept being in the minority on that point). > > > Fossil's poor handling of symlinks is a severe knock against it, both in my opinion and in my experience with proselytizing it to people who are not already on the fossil kool-aid.
Philosophically, I think of links as build artifacts, which are rarely stored in an scm. I do avoid them as much as possible, but I've occasionally wondered: does anybody manage the links as the build artifacts of a script, and keep the script itself under version control? So, if you need: foo -> bar, do this: #!/bin/sh ln -sf bar foo ... and store that script under VC? > Every time a user opens our repo on unix, the symlinks are initially populated as regular files whose contents are the link target. This is causes me significant embarrassment for recommending fossil when others on my project have to deal with it. (I tried pushing through a code patch a year or so ago to fix this, but I detected some bug or another with it and I don't think the devs ever accepted the patch (not sure).) > > Note that this a Fossil-specific quirk. Not all cross-platform programs are equally awkward in their symlink handling -- in fact, most are better. > > Stephan: I think that you are overcomplicating the matter, in the sense that the complications you note can (and should) be passed on to the user -- in the same way that the program tar(1) might pass on such complications to the user when trying to move a tarball from one OS to another. In other words, I believe that you perceive a dichotomy that is false (between (a) not implementing symlinks at all and (b) implementing them while having fossil perfectly and automatically solve all complications that may arise). > > A user who only ever uses fossil on unix should get unix symlink semantics on unix, without quirks or surprises. Surely you and DRH would agree with that? > > The cases you are worried about: > > * absolute paths -- fossil can preserve the absolute path, it's the user's fault if that's the wrong thing to do. > * broken links -- fossil preserves the original link, it's the user's fault if the link is incorrectly broken. > * cross-platform semantics -- implement the proper semantics where you can, and don't where you can't. A user who only ever uses fossil on unix should get unix symlink semantics on unix. If the fossil devs are able to implement proper symlink handling on next year's Windows, then awesome. If not, then degrade to whatever and document it for the user (emitting warning messages as appropriate or so on). > > Stated yet another way: we don't expect the SCM to solve all problems that users create. An example is naming branches incorrectly. If the user names a branch "aaaa" when the project has a rule that branch names should be descriptive, we don't expect Fossil to flag it and deal with it -- we expect the user's coworkers to yell at them til they fix it. So it should be with symlinks -- each project has its own rules, Fossil doesn't know about those rules, Fossil just faithfully syncs the target around, and if a link gets broken in violation of project rules then a user gets yelled at by another user. (Note that the project-local rules might be "never use symlinks because our Windows doesn't handle them how we would like" or "we think symlinks are always perverse". Fossil should not IMO be constrained by such subsets of the user base.) > > For context, my particular use case: we need the openssl source tree in our project, and that tree contains internal symlinks. Again, people have to jump through silly hoops to get new repos set up properly, because fossil breaks those symlinks by populating new repos with flat text files (and this goes undiscovered til the openssl build fails in mysterious ways). So their first experience with Fossil winds up being a pretty big "WTF". > > My $.02, > Eric > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
