On Sat, Oct 31, 2015 at 11:33 AM, Stephan Beal <[email protected]> wrote:
> On Sat, Oct 31, 2015 at 6:45 PM, Matt Welland <[email protected]> > wrote: > > [snip] > (i) Is fossil that much less arcane? Last I checked mv, cp and rm don't >> work the same as Unix, an ongoing annoyance for my users, then there is the >> bizarre choice to treat symlinks as files by default - does any other SCM >> do that? This bit me *again* recently and I'm still grumpy about it >> > > fwiw, i have always been against the idea of fossil supporting symlinks at > all, despite me being a 100% unix user, simply because they aren't portable > and they open up philosophical cans of worms like how to hand links leading > outside the repo root. i _never_ use symlinks in any SCM. Support for the > +x bit (also not portable) was added relatively late, and primarily (only?) > to accommodate the convention of having an executable ./configure script. > (Not having executable scripts was really annoying.) > In the electronic design industry symlinks are used extensively in SCM controlled areas. Most often this allows omitting a build step where the controlled files are scripts or other plain text data. Without good symlink support fossil is eliminated from consideration. In supporting a cross platform tool I think it is better to degrade gracefully rather than simply design for the lowest common denominator. Windows will ultimately get decent symlink support. Why not be ready for it with good support in fossil? Symlinks can be meaningfully viewed as a special file, handled internally as a one line text file, implemented on disk as a symlink where supported or as a one-line file where not supported. Conceptually it is not that complicated. The default in fossil to follow symbolic links is hugely problematic. It is impossible for fossil to automatically reproduce an originating working area which was constructed by symlinking different areas on disk to a single directory structure. Given that to recreate the original structure manual effort is required after clone/open, this model makes no general sense in the context of an SCM and should not be the default. Making following symlinks available as an option is great and could be useful for some use cases. But as a default it severely violates the principle of least surprise for Unix users, at least in my professional experience. BTW, as best I can tell git by default treats symlinks as symlinks and does not support following links at all. BTW, to some extent it is ok for fossil to be opinionated software that strives to dictate how to do your work. However take that model very far and you quickly alienate people. Given that perspective, why would fossil care if someone chooses to commit a symlink that points outside their repo? Give that user some credit, presumably he or she has a good reason for doing what they are doing. Happy Halloween, > Indeed! Happy Halloween! > > -- > ----- 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 > >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
