On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith <eas....@gmail.com> wrote:
> 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). > That sounds like a fair summary of my feelings on SCM support for symlinks, but i'd argue that if a system (SCM) cannot do (b) for the vast majority of use cases, then it probably shouldn't be implemented at all. Why not? Because it's the _displeased_ users who complain the loudest when something doesn't work how they want/expect it do, and that percentage of users is relatively high in the case of symlinks. 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? > i can't speak for Richard, but if i had my way, fossil wouldn't support symlinks at all. They are inherently platform-dependent and, IMHO, belong in the build process, not the SCM. They are a big can of worms, as we can see by large amount of emails on the topic. To be clear: i use symlinks all over the place on my systems, i just refuse to use them in an SCM. Call me old fashioned. > <he 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. > Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous link to /etc might be wrong in certain build environments (and won't work on Windows). Why should fossil assist in doing the wrong thing? Stated yet another way: we don't expect the SCM to solve all problems that > users create. > But if it sets out to solve them, then it should solve them, not provide a half-solution to philosophically unsolvable problems. (IMO.) > 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). > To the best of my knowledge, if symlinks are enabled in the fossil config, it will DTRT with them (to the best of its ability). i haven't tried it, but that's my understanding of the feature. IIRC symlinks are on by default on Unix systems and off everywhere else (that info might be outdated, though). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
