you are perfectly right with your assessment, I had other/additional use
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

Does this make sense? At least from a workflow perspective?


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

Reply via email to