> On Windows (which is what the "non-technical" people will probably be > running) you cannot write to an executable file while it is running.
Again correct: we are mainly talking about Windows where an executable cannot write to itself --> read-only it must be. That brings us to the update scenarios Stephan mentioned: * there cannot be an automatic "self-update" of this self-contained repository/exe (which would be a very nice feature, but seems fine for my UC) * updates need to be done via an external fossil.exe via explicit push to that self-contained repo/exe, which would be fine for me as wellas this would then be done by the "technical" staff Regarding the problem areas mentioned below: > (1) The server keeps running until the user shuts it down. Seems to be ok as ... > (2) ... Windows will pop up a DOS box ... ... and even non-technical people can click the [x] close button on this dos-box window. So I see the dos-box to be a feature rather than a problem :-). AND: if this is really going to be a feature within fossil I'd go with a least possible risk/impact version of it. IMHO That would really just include the read-only access via "fossil ui" and even there I would make the usage of an attached repo explicit as we'd need the ui cmd-line option anyway and as such we won't change the behavior for others that don't want/need it. e.g. "fossil ui --self" Chris _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
