> - Symlinks. Now we're getting into file system specifics. Some users > may want to track them because they find them useful. What about users > that find FIFOs or block devices or character device useful? Should > fossil attempt to save enough information to recreate them? >
Support for FIFOs and block devices is a separate discussion. My defense of symlink support does not force me to also defend FIFO and block device support. > - Extended attributes. Many file systems now have extended attributes. > Should Mac users complain because fossil doesn't support HFS+ extended > attributes or resource forks? > They may do so if they think it's reasonable, and be subject to all the usual considerations around developers' time and attention, etc. But again, for the purposes of arguing whether good symlink support is warranted, that is a separate topic. > I think fossil can support the permissions level. Anything further > down in the previous list should be part of the project's build cycle. My biggest complaint about this discussion is that some folks seem to be coming at it like fossil is the first tool to confront this issue. It isn't. There are real examples of programs in the wild (SCMs, no less!) that have solved it in ways that are more coherent, more user-friendly, and just as easy to implement as what fossil already has. For Git, our poster-child for difficult tools, this is just a total non-issue. Fossil already sort-of attempts to do what Git does, it just has some bugs and incorrect default config values. So the distance to fixing Fossil is quite small. But closing the gap (and keeping it closed) is much harder when a vocal subset of the community argues that supporting symlinks is impossible or ill-advised (it is neither, by my lights). Eric
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
