FWIW: The three Fossil self-hosting repositories stay in sync via a cron job running on each server. See https://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for additional information;.
On 4/8/15, Richard Hipp <[email protected]> wrote: > On 4/8/15, [email protected] <[email protected]> wrote: >> Is anyone interested in a diff with this functionality? I don't mind >> digging into the code, but I don't want to waste my time if it goes >> against a core idea of Fossil. I'd just like the option of using it >> with nothing external-facing other than SSH. >> > > This does not go against any core Fossil ideas. I just think it might > be tricky to implement. > > The way the web interface works is that each HTTP request is handled > by a separate process. In other words, a new "fossil" process is > forked for each incoming HTTP request. That subprocess receives the > HTTP request (in your case a ticket update) and then sends a reply > back to the client, and then exits. > > The change you propose would be that the subprocess continues running > after sending the HTTP reply and does a sync to its registered server > (if it has one). > > Some potential problems: > > (1) How do you handle errors? The HTTP reply has already been sent. > There is no way to notify the user that something went wrong. > > (2) If you try to deal with (1) by delaying the HTTP reply until after > the sync takes place, then a slow sync will seriously delay the HTTP > reply, which will make the interface seem to "freeze" form the point > of view of the user. > > (3) Depending on how the subprocess was originally launched (CGI, > SCGI, inetd, ssh, etc) the parent process might kill off the > subprocess after receiving the HTTP reply, but before the subprocess > has finished doing the sync. > -- > D. Richard Hipp > [email protected] > -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
