4 ms·
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
by thayne 3y ago
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.
- velcrovan 3y agoWhat 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.
- blagie 3y agoRedundant? 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.