Hi, you are perfectly right with your assessment, I had other/additional use cases in mind targeting more non-developers.
Just to explain: e.g. developer/technical people are doing an analysis and generate code as well as results. With fossil that's easy to keep together and the (mostly, in my case) markdown files with images are in the same repo as the code that are used to generate these results. In order to provide this information to "other" people I need to export the docs into another format (html, pdf) and version it accordingly so that I can trace from which version the doc has been generated.. OR (my use case now) I can provide one executable on that they start locally on their computer and point their web-browser to the localhost url. BAM documentation including version information. no handling of individual files no export, no version mix-up. And I can use all the nice features of fossil to render the embedded docs and serve static files. Maybe this is very special for my environment (big company, various level of skills involved within such an analysis). I agree that a full fledged dev or server use case has lots of pitfalls with this AppendVFS, but that was not what I had in mind. I guess even read-only access to this attached repo would be fine for my UC. Maybe this could even alleviate some of the problems that you mentioned below. So I did not consider CGI, server side hosting, various upgrade scenarios,etc.... Does this make sense? At least from a workflow perspective? Thanks chris Am 12.05.2018 um 14:09 schrieb Stephan Beal: > On Sat, May 12, 2018 at 1:51 PM, Chris Drexler > <ckolum...@ac-drexler.de <mailto:ckolum...@ac-drexler.de>> wrote: > > Thoughts? If someone could hint me at the right place within the > fossil code I could also try to provide an implementation. > > > IMO: every clone would not have that feature, so it would seem (to me) > to be of limited use. The only benefit would be that you only have 1 > file, instead of 2, to copy to the remote server. (If you build your > binary on that server, even that benefit is lost.) If your server is > upgraded in a way which becomes incompatible with your fossil binary > (incompatible SSL upgrade or (possibly) libc upgrade), you're hosed: > the repo is then locked inside a binary file which other fossil > binaries cannot read. (i've had hoster-side OS upgrades break my CGI > binaries before, though i don't think i've seen it happen to my fossil > binaries.) > > Another point to consider: the binary itself would have to be writable > by the web server process, which opens up a potential security hole. > In my experience, Apache runs CGI scripts as the account holder (as > opposed to some generic 'www' user), and that account holder already > has write access to the binary. However, i make my CGI bins read-only, > even to myself, "just in case" (because one too many wordpress > vulnerabilities have made me paranoid in that regard). > > It sounds to me like such a feature is tantamount to walking a > minefield in which any given mine could leave you unable to access the > repository data. > > Just my opinion, of course. It may very well work out fine for you. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > "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
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
