On Tue, Nov 3, 2015 at 4:48 PM, Eric Rubin-Smith <[email protected]> wrote:
> > On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal <[email protected]> > wrote: > >> >> 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? >> > > Here you give away the game by saying "IMO". Whether it's wrong is a > question of policy, as you seem to admit. And such examples have clearly > led you down a path of arguing that your policy is the right one -- to the > detriment of the tool. > You've hit it right on the head: POLICY. No SCM should enforce project-specific policies, and symlinks (for me) fall into that category. > Your particular example is actually great for my case, because it applies > with equal force to the case of filesystems. A filesystem can be mounted > at any mount point, so an absolute symlink to '/etc' that works fine when > the FS is mounted at '/' will not be correct when the FS is mounted at > '/foo/bar'. So absolute symlinks are also wrong in this case. Why should > Linux assist in doing the wrong thing? > The OS is there to make anything possible. An SCM is there to track source code (which, by long-standing convention, exists in one tree). That's comparing one fruit with another fruit (sorry, but a certain luxury hardware vendor has ruined the more conventional phrasing of that for me). > >> 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.) >> > > Your argument is analogous to an argument that compilers can't detect and > correct all program bugs, so we may as well not write compilers at all. > This is an enormous problem, you could argue, because almost all programs > have bugs, and so the compiler is doomed to fail almost every time! > Again, fruit and other fruit. An SCM has a very specific target, whereas a compiler is there to make _anything_ possible. > We can support symlinks without setting out to solve all problems that > arise. It's not a half-solution -- it's a full solution to a narrower > (and, in fact, pretty simple) problem. > If it were that simple, it likely would have been done to the majority's satisfaction by now ;). > It defaults to off, and it should go without saying that a "do the right > thing" setting should default to on. > i disagree - "off" is the most platform-compatible option. i want all of my source trees to check out identically on all platforms, and that cannot happen if i've got a symlink in there. (That said, i _thought_ it defaulted to "on" for Unix platforms.) My thoughts on symlinks in SCMs can be summarized accurately in 3 words: "can of worms." -- ----- 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 [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
