1. The running fossil serving the request must have a current directory within a "fossil open" checkout or exactly one repository must be specified on the command line (not a directory). [It appears that a single-repository cgi script is no longer good enough as the repository is closed by the time the process_sync_args function runs and since no repository name is available in the options list (it's embedded in the script instead) fossil fails to find the repository.]

2. The environment must have a HOME (or equivalent) variable set to a path that allows writing/creating both .fossil and .fossil-journal files. [This may be a particularly challenging requirement to satisfy in a secure manner when the fossil cgi is running as the www user on a web server. Although certainly using the /usr/bin/env command in the #! line of a fossil cgi script to set HOME then run fossil may be of some help here, but that seems clumsy.]

This breaks down if fossil was started with the "fossil server directory" option (or the corresponding fossil cgi "directory: ..." option). Which repository will get sync'd when you select "Sync Now"? In fact it looks like if the above conditions are true, you'll always sync the same repository which may or may not be related at all to the the repository being viewed via the web ui.

However, for the "fossil ui" command only, none of the above applies since a single repository must be specified and it's reasonable to expect the conditions listed above to always be satisfied correctly.

Is it possible to just suppress the "Sync Now" option unless the command that started the server was "fossil ui"?

P.S. Even when using "fossil ui" to run the "Sync Now" option (and it does work) the sync progress output corrupts the content being returned -- all the progress details from the sync are output before the initial "HTTP/1.0 200 OK" response so it's kind of surprising that the browser even displays the real html content correctly at all (after the mash of sync progress output at the top of the page). It might be simpler just to get rid of the web interface to "Sync Now" completely.

drh added on 2010-04-22 15:22:03:
I agree that the current Sync Now implementation is entirely inadequate and has been removed. But this reopens feature request [3b1533a090eebd09] which seems to be a real need. There needs to be some mechanism added back to SQLite to do a sync or push or pull from the web interface for use on servers without command-line access.