I have a repo that I will be sharing via CGI on my website. I would like people to be able to clone this repo, but in general they will not have commit permissions. This means that if they commit any changes to their local copy, they will get permission errors when the autosync happens.

In order to improve their experience, can I arrange it so that their clones will have autosync set to 0 or pullonly by default?

The checkin still occurs in the local repo when this happens. The warning is just telling you that the sync failed.

I'd just recommend "fossil set autosync 0" as part of the cloning instructions.

In fact, if ease of use is the primary concern, I'd just point them at a tarball or Zip file of the repo trunk, which Fossil easily provides. See "fossil help /tarball" and "fossil help /zip".

You raise good points. My immediate concern is that for most of my users this will be their first exposure to Fossil, they will be watching the output, and seeing "Autosync failed" will raise flags for them that they did something wrong, or missed a step, etc.

I really like both of your alternatives. A warning like "Skipping automatic push to $SERVER (user lacks commit privilege there)" might do very well for either.

I could tell potential users to turn off autosync right away as Warren suggested. Indeed, as things stand, this was my plan. But if we did either of these, they wouldn't have to, and as you point out, they also wouldn't have to remember to turn it on later if their permissions get upgraded. And it's kinder and more useful than just saying "It failed".

Will any user commit to your repo? If not, then I think what Warren said about getting the latest tar/zip is a good idea.

What would be the advantage of your users cloning the repo if they won't have commit access?

I'll partially contradict myself by arguing the other side now. Ready? :)

The advantage is that new versions published on the Fossil repo are a quick sync away, which is more efficient than copying the whole tarball back down and unpacking it over your previous version.

That's how I distribute one of my public Fossil-based projects: a binary OS image that they flash onto an SD card, containing the project's software, built and ready to go, plus Fossil and a clone of it opened and ready to use. To update, they just "fossil up && make && sudo make install".

advantage is that new versions published on the Fossil repo are a quick sync away

Yep, that's right. Even a shell alias is quicker. I used to have something like fossilup, which would cd into the fossil repo, fossil up trunk, config, make, make install. That saves many manual steps.

If joeld plans on having a very active repo, he could advertise the tarballs as "nightly" and make them available each night at a given time, replacing the previous build. Otherwise, like Warren said, make it a simple line item in your repo clone to disable autosync.

I think drh's thought (about making the error more informative) is better than either of these. It makes things more seamless, both when a new user clones and down the road whenever their permissions are upgraded. I can’t see what the downside would be.

Please rebuild using the latest check-in and let me know if that works for you.

Some users might get commit access later on. But even if they don't, they may wish to submit patches, and this will make that process better for both of us. They may also wish to keep their copies in a source control system for their own use. If they choose to keep it in Fossil, they'll have perpetual access to the wiki, tickets, etc.

In other words, I would like to introduce my users in a practical way to the virtues of Fossil without necessarily bringing them on board as core developers. I will probably also offer the tar/zip option as well, but I would like to try and sell them on keeping it in a Fossil repo because there are benefits to them.

In other words, I would like to introduce my users in a practical way to the virtues of Fossil

Go forth and multiply the Fossil community!