> 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
  (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

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"


fossil-users mailing list

Reply via email to