Version Control with Subversion - Login

Repository Administrationthe source repository and read/write access to the destination repository.When using svnsync against a remote source repository, the Subversionserver for that repository must be running Subversion version 1.4 or later.Assuming you already have a source repository that you'd like to mirror, the next thing youneed is an empty target repository that will actually serve as that mirror. This target repositorycan use either of the available filesystem data-store backends (see the section called“Choosing a Data Store”), but it must not yet have any version history in it. The protocolthat svnsync uses to communicate revision information is highly sensitive to mismatchesbetween the versioned histories contained in the source and target repositories. For thisreason, while svnsync cannot demand that the target repository be read-only, 12 allowingthe revision history in the target repository to change by any mechanism other than the mirroringprocess is a recipe for disaster.Do not modify a mirror repository in such a way as to cause its version historyto deviate from that of the repository it mirrors. The only commits and revisionproperty modifications that ever occur on that mirror repository should be thoseperformed by the svnsync tool.Another requirement of the target repository is that the svnsync process be allowed tomodify revision properties. Because svnsync works within the framework of that repository'shook system, the default state of the repository (which is to disallow revision propertychanges; see pre-revprop-change) is insufficient. You'll need to explicitly implement thepre-revprop-change hook, and your script must allow svnsync to set and change revisionproperties. With those provisions in place, you are ready to start mirroring repository revisions.It's a good idea to implement authorization measures that allow your repositoryreplication process to perform its tasks while preventing other users from modifyingthe contents of your mirror repository at all.Let's walk through the use of svnsync in a somewhat typical mirroring scenario. We'll pepperthis discourse with practical recommendations, which you are free to disregard if theyaren't required by or suitable for your environment.As a service to the fine developers of our favorite version control system, we will be mirroringthe public Subversion source code repository and exposing that mirror publicly on theInternet, hosted on a different machine than the one on which the original Subversionsource code repository lives. This remote host has a global configuration that permits anonymoususers to read the contents of repositories on the host, but requires users to authenticateto modify those repositories. (Please forgive us for glossing over the details ofSubversion server configuration for the moment—those are covered thoroughly inChapter 6, Server Configuration.) And for no other reason than that it makes for a more interestingexample, we'll be driving the replication process from a third machine—the onethat we currently find ourselves using.First, we'll create the repository which will be our mirror. This and the next couple of stepsdo require shell access to the machine on which the mirror repository will live. Once the repositoryis all configured, though, we shouldn't need to touch it directly again.$ ssh admin@svn.example.com \"svnadmin create /var/svn/svn-mirror"admin@svn.example.com's password: ********$12 In fact, it can't truly be read-only, or svnsync itself would have a tough time copying revision history into it.147