It is non-trivial to stand up a redundent, highly-available, and scalable git server. And if you throw in "with a good web interface", even moreso. But I doubt that is trivial to do with fossil either.
What do you mean by redundant, highly available? Under what circumstances are those necessary? Whatever it is, seems completely orthogonal to version control software. Anyways, I can serve a fossil repo with a great web UI and a few 9s of reliability on an existing web server with literally a 2-line CGI script.
I think at some point, you missed the point of a DVCS.
Scalable?
When do you run into issues with git server scalability that an 80486 couldn't handle?
Highly-available?
At this point, just pay for !@#$ github. But it's a heck of a lot easier to do this in a DVCS than in fossil. Options:
- Set up two servers. Add a hook to push from one to the other whenever a change happens. If the main server goes down, swap to the backup, and bring up a new one as a backup.
- Store the git repo on a redundant, highly-available, scalable file system, and run a few git servers on the shared file system. Back in my day, we'd use AFS for this.
The nice thing about the data model is these solutions /work/. The basic git data model* won't be corrupted if multiple systems are writing to it more-or-less simultaneously. Absolute worst case is the tree splits and you've got a detached head somewhere, but no data is lost.
* I can't speak for some of the more advanced stuff (packing, compression, etc.), since I don't fully understand it; but it's possible to disable all of that.
