Version Control with Subversion - Login

Repository Administrationtrigger the pre-revprop-change and post-revprop-change hooks. 14 And since you canchange revision properties without respect to chronological order—you can change any revision'sproperties at any time—an incremental backup of the latest few revisions might notcatch a property modification to a revision that was included as part of a previous backup.Generally speaking, only the truly paranoid would need to back up their entire repository,say, every time a commit occurred. However, assuming that a given repository has someother redundancy mechanism in place with relatively fine granularity (such as per-commitemails or incremental dumps), a hot backup of the database might be something that a repositoryadministrator would want to include as part of a system-wide nightly backup. It'syour data—protect it as much as you'd like.Often, the best approach to repository backups is a diversified one that leverages combinationsof the methods described here. The Subversion developers, for example, back up theSubversion source code repository nightly using hot-backup.py and an off-site rsync ofthose full backups; keep multiple archives of all the commit and property change notificationemails; and have repository mirrors maintained by various volunteers using svnsync.Your solution might be similar, but should be catered to your needs and that delicate balanceof convenience with paranoia. And whatever you do, validate your backups from timeto time—what good is a spare tire that has a hole in it? While all of this might not save yourhardware from the iron fist of Fate, 15 it should certainly help you recover from those tryingtimes.Managing Repository UUIDsSubversion repositories have a universally unique identifier (UUID) associated with them.This is used by Subversion clients to verify the identity of a repository when other forms ofverification aren't good enough (such as checking the repository URL, which can changeover time). Most Subversion repository administrators rarely, if ever, need to think about repositoryUUIDs as anything more than a trivial implementation detail of Subversion. Sometimes,however, there is cause for attention to this detail.As a general rule, you want the UUIDs of your live repositories to be unique. That is, afterall, the point of having UUIDs. But there are times when you want the repository UUIDs oftwo repositories to be exactly the same. For example, if you make a copy of a repositoryfor backup purposes, you want the backup to be a perfect replica of the original so that, inthe event that you have to restore that backup and replace the live repository, users don'tsuddenly see what looks like a different repository. When dumping and loading repositoryhistory (as described earlier in the section called “Migrating Repository Data Elsewhere”),you get to decide whether to apply the UUID encapsulated in the data dump stream to therepository in which you are loading the data. The particular circumstance will dictate thecorrect behavior.There are a couple of ways to set (or reset) a repository's UUID, should you need to. As ofSubversion 1.5, this is as simple as using the svnadmin setuuid command. If you providethis subcommand with an explicit UUID, it will validate that the UUID is well-formed andthen set the repository UUID to that value. If you omit the UUID, a brand-new UUID will begenerated for your repository.$ svnlook uuid /var/svn/reposcf2b9d22-acb5-11dc-bc8c-05e83ce5dbec$ svnadmin setuuid /var/svn/repos # generate a new UUID$ svnlook uuid /var/svn/repos3c3c38fe-acc0-11dc-acbc-1b37ff1c8e7c$ svnadmin setuuid /var/svn/repos \cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec$ svnlook uuid /var/svn/reposcf2b9d22-acb5-11dc-bc8c-05e83ce5dbec# restore the old UUID14 svnadmin setlog can be called in a way that bypasses the hook interface altogether.15 You know—the collective term for all of her “fickle fingers.”154