![]() ![]() ![]() #Subversion sync codeCommit some code as normal (to source-repo), then browse to your mirror-repo or do an svn info on it to make sure your commit made it over to mirror-server. Svnsync -non-interactive -username syncuser -password XXXXXXX sync & Here’s the script I used for the pre-revision property change hook on Windows: This hook is a perfect place to put your check that only syncuser is allowed to do things. Some tutorials have you simply add the line exit 0 to your script, but I would recommend against this approach because it leaves the door open for some other user to modify properties and muck up the works. In order to do this there has to be a valid pre-revision property change hook on the repository that calls exit 0. It does this by setting some properties on the repository at -r 0. The svnsync program needs to store some special properties about its own syncronization activities. Now at this point, we have an empty mirror-repo at revision 0. This is the only user that will need access to the mirror-serverrepositories. Don’t check the box to create branches, tags and trunk! Then add a new user, syncuser. Just click to the administrative interface and right-click on Repositories container create a new repository. In my case, using VisualSVN makes this incredibly simple. You can actually “play back” these changes on the mirror-repo starting from revision 0 forward, but in most cases it’s faster to dump the source and load it onto the master. Step Two: Dump the Source Repository Unless you’re starting fresh with both an empty source-repo and an empty mirror-repo, chances are you have lots of commits on your current source-repo. #Subversion sync installWhether you install from source or from a binary, it’s important to at least know what version of Subversion each server is running. #Subversion sync windows 7In our case, we have our source-server repository running Subversion 1.6.6 on Ubuntu Server 10.04 LTS, and I set up the free version of VisualSVN 2.06 (bundled with Subversion 1.6x) on a Windows 7 PC. More details in Chapter 9: Subversion Repository Mirroring in the SVN Book. Why? As of Subversion 1.7, you can now use svnsync with the new -allow-non-empty option, which is designed for exactly the situation of starting to sync a mirror when it already has content in it. ![]() I purposely downloaded an older version of VisualSVN 2.06 bundled with Subversion 1.6.17, and later found out I would’ve been better off running the latest VisualSVN 2.5.3 bundled with Subversion 1.7.3. Unfortunately, I didn’t realize that when I started. What’s interesting to note here is that unlike most database replication setups, with Subversion, it doesn’t matter too much what version the server is, or what platform you want to run it on. We’ll call that mirror-server from here on out. The first step is to set up a second Subversion server to be used as a mirror. We’ll call that source-server from now on. Step One: Set up Subversion on a 2nd Server This guide assumes you’re already running Subversion on one server. Following are the steps and a few gotchas I learned this week as I finally had a chance to set up a proper Subversion mirror replication slave server. If you’re familiar with master-slave database replication, Subversion repository replication is quite similar. The best way to do this is to create a mirror repository on another server, and use the svnsync program to create a replica of your primary Subversion repository, or repositories, if you have multiple. To extend the insurance metaphor, as great as it is having the code on your laptop backed up to a central Subversion server, it makes just as much sense to protect yourself from the possibility that your Subversion server’s hard drive will crash. Granted you can do the same thing with a master Git repository on or your own server in the cloud, but unlike Git, Subversion is meant to be run somewhere other than your laptop or workstation. Every time you commit, you’re sending that code to another server. One of the primary benefits of using Subversion as your SCM solution is that it’s like having an insurance policy against your local machine breaking, your laptop being stolen, or your hard drive crashing. That is, when you use Git to commit hundreds or even thousands of revisions to your local machine… what happens if your hard drive crashes? Unless you also have set up a remote repository and get familiar with pull requests and merges - Git actually requires a little more effort to get this big benefit - and it’s built into Subversion by design. Tons of developers love Git, and although Git does have some really great features when compared to Subversion, there’s one particular benefit to using Subversion that Git users rarely consider. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |