Update, May 2005: The following is a little esay I wrote to blow some steam off in June 2004, when I used subversion for a while. Apparently it contains bad language -- please do not read on if you are easily offended. Please note that since that date, subversion has changed beyond belief and is now perfect.Subversion is a version control system. Like CVS. It is designed as a successor to CVS, improving the functionality, speed, without losing the elegance and simplicity of CVS. Subversion has indeed the features that CVS is lacking, you can move files, and you can easily tag releases. It is also blindingly fast, and it has used the same update/commit approach that CVS uses. So far so good.
The reason I am no longer touching it with a bargepole is the implementation. svn has been implemented using Berkeley databases. Presumably because they are fast and efficient. All releases of all files are stored in a single database. This is fine, efficient, and everything else, until your database gets corrupted. At that stage you are up to your chin in shit.
The database is easily corrupted. In my case I added some memory to a machine, without knowing that the memory was flaky. The machine still worked, with the odd crash. Took the memory out again and the machine was stable again. At that stage I went to my client machine, and typed the usual command to commit some changes that I had made.
svn commitThe answer that comes back is 'Network connection unexpectedly closed'. I did the sensible thing, and went to Google to find out why svn would say something like this. Shock, horror, the web did not have an answer, other than people asking the question 'What does this error mean', only to get an answer 'Have you read Section X.Y of the subversion book'. Not helpful because the subversion book doesn't tell you either... So in a moment of desperation I started a server by hand, and hung an strace on it, the final dying moment of the process is a SIGABRT, just after it opens the database files.
By now several horror stories of corrupt databases that I have seen on the web come to my mind. Indeed, searching for 'corrupt svn' gives some answers. In particular, it is recommended to recover your subversion archive:
svnadmin recoverOne is warned that this command may take several minutes to complete, but in my case the answer came within a second: it said that my database was corrupted. That was not the answer I was waiting for, I asked svn to recover, not to tell me that it was broken. I went back to the web for help, and there are now many pages that contain the answer:
"This is not subversion's fault, it is the database that is corrupt"Three things come to mind: this statement is true, not very helpful, and the shit is deeper than I thought. The advice is now to recover the database rather than subversion:
db_recoverThis program is also extremely fast in analysing the problem. It told me that there was an 'Error in log file'. It does not recover anything... In a desperate move I decided to remove the log files, and to my surprise everything recovers, db_recover works, svnadmin recover works, until you do anything with svn, whereupon you are back to square one. In short, all your previous releases are gone. What you are left with is what you have checked out.
I am back to CVS. When there is a problem, whether caused by flaky memory, an unreliable hard-disk, or a programming error, I know that part of the repository will be corrupted. I know that one include file down there will contain a block of all zeroes. I know that half my files may be committed, and the other half isn't. But when shit happens (and shit happens) I will be able to repair it using, vi or emacs...
Subversion is a wonderful design, but the implementation has strayed too far away from things that we can understand.
For lots of fuming reactions see SlashDot, where some anonymous person (not me) posted a reference to this page. Apparently I am an idiot, I am glad I made your day!