Whenever you have a database, there's a question of transaction
synchronization. Most databases use multiple files that are updated when a
transaction happens. If you back up file "A" in one state of the transaction
while file "B" is in another state, you run the risk of not being able to
restore your backup.
Source code repositories might not necessarily be a SQL database, but they
are a database, and liket databases, their repository are stored over
several files that must be maintained in a sychronized manner. The svnadmin
hotcopy command takes care of this problem by copying the Subversion
repository in a safe manner. If the repository is corrupted, you can easily
restore the hotcopy.
However, the svnadmin hotcopy does have an issue: It is hardware/software/OS
specific. Change one of those, and you cannot use the hotcopy'd version of
your backup. That's where the svnadmin dump comes in. This is a dump of your
Subversion repository that can easily be loaded into a new Subversion
repository without worrying about hardware, software, or the OS.
This issue isn't just a Subversion issue, but also an issue with almost
every single source control repository out there. Make sure your Subversion
administrators do a backup (either hotcopy or dump) before you do the tape
backups. If the repository is so large that backups take too long, have your
Subversion administrators use an incremental dump to only dump out the
newest transactions.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408611
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-18 06:42:07 CEST