Related

When unstable is just not unstable enough

Ubuntu release 9.10 a bit early

ASUS My Cinema U3100 Mini DMB-TH - MythTV fully working

ASUS My Cinema U3100 Mini DMB-TH - Partly working

Source code for ASUS My Cinema U3100 Mini DMB-TH

Bluetooth GPRS via an A1200 and peoples.net

Mythtv xmltv importer for HK

captcha death and mod_proxy mistakes.

mod_proxy as a spammer

to 64bit or not.., and new office

Subversion, not ready for prime time...

Published 2004-05-23 18:53:17

I upgraded a few months ago to subversion 1.0, hoping that the database corruption problems I had seen repeatadly with the pre-1.0 series would have been ironed out. Unfortunatly, not yet.

Having re-built all my repositories on a new server (the old one had disk coruption issues, which aggitated the problems with subversion). I got the first corruption, thankfully I have a copy on commit script, so although this new server was not backed up, at least the current state of the repository is retrievable.

Personally I think the problem behind subversion is a serious design flaw, depending on a single file (db/strings) to store the whole repository, to put it politely, is not particulary smart..., not only does it get huge too easily, but any corruption in the filesystem, or file leaves you succeptable to loosing a whole repository. Perhaps a per directory strings file, and a database of directories, would help a bit.. - at least you would only loose a directory occasionally. - but realistically CVS's per file archive, and a master log would be a far better solution.

In conclusion
  • Never run a subversion server without a backup script! (you may as well be putting your data in a trash can)

Mentioned By:
google.com : subversion backup (291 referals)
google.com : php subversion (247 referals)
google.com : backup subversion (92 referals)
google.com : php svn server (89 referals)
google.com : php subversion server (87 referals)
google.com : april (62 referals)
google.com : december (49 referals)
google.com : subversion backups (33 referals)
google.com : subversion corruption (33 referals)
google.com : subversion backup script (25 referals)
google.com : subversion hotcopy (25 referals)
google.com : svn server php (24 referals)
google.com : hot-backup.py (20 referals)
google.com : subversion backup cron (17 referals)
google.com : subversion php (17 referals)
www.answers.com : subversion cron backup script: Web Search Results from Answers.com (15 referals)
google.com : how to backup subversion (15 referals)
google.com : "php subversion server" (13 referals)
google.com : svnadmin hotcopy (13 referals)
google.com : subversion strings file (11 referals)

Comments

testing this works.
#0 - Alan Knowles ( Link) on 2004-05-23 21:36:27 Delete Comment
Well I've been using Subversion for a couple of months now and I haven't had any problems at all. Actually it's been _much_ more stable than any other source control that I've used. Also keeping any source control (or pretty much anything else) without a backup is a stupid thing.
#1 - Mladen Mihajlovic ( Link) on 2004-05-23 23:26:40 Delete Comment
What constitues a backup commit script? Are these problems documented elsewhere? I currently rely on subversion and this is troublesome. Initially I found the arch syntax combersome but perhaps I sould switch to arch...

culley
#2 - culley ( Link) on 2004-05-26 11:04:15 Delete Comment
Basically something like this in a cron job.
svnadmin dump /my/repos | gzip | /var/backup.$DATE.gz

Although it's not very effecient (eats disk space alive).
#3 - Alan Knowles ( Link) on 2004-05-26 12:25:38 Delete Comment
I looked into this a little more and svnadmin has some facilities for creating backups (svnadmin hotcopy) and there is a python wrapper around it too (hot-backup.py).

http://svnbook.red-bean.com/svnbook/ch05s03.html#svn-ch-5-sect-3.6

I feel pretty safe using this for my repository which is quite small. This probably wouldn't be too practical for a big project like, say, postgresql...

culley
#4 - culley ( Link) on 2004-05-26 22:55:51 Delete Comment
A single file is what I expect from a database. Maybe one file for log and one file for data. And hot backups, of course, from database or log. I don't understand why so many files if one of the big changes from cvs to subversion it's the consistent commit. If I lost one file it became out of sync with other code. Every source control server *must* be backed up in a consistent way. I don't think the Berkeley database about use a lot of files is useful, because a database is yet more sensible regarding to consistence. The decision of splitting the data across files supposes to be a database (in this case a repository) administrator's task.
#5 - xyko ( Link) on 2004-09-28 21:29:58 Delete Comment

Add Your Comment

    Follow us