Svn – Performance difference between subversion checkouts and exports

What protocol are you using? If its http, you will need to look at your Apache setup too.

If nothing on the server is 100% CPU, then the problem is more likely to be network based, or subversion server is having difficulty reading the files from the disk - so check out the server disk IO.

Even so, 3-4 minutes is a major slowdown, so I would think something major is going wrong. iostat or iotop are disk perf monitoring tools, or use an all-in-one monitor like saidar or nagios

Your RabbitVCS fix is not likely to have done anything (if it affected Windows and Linux clients), chances are whatever was hammering your server has stopped... for the time being at least.

I've used something like this before; this is how it worked.

Repo Setup

1. Create a git repo, "etc_files".
2. Create a branch for each machine type, e.g., "server/www", "server/dev", etc.
   • git supports slashes in branch names. This helps me keep the branches straight in my head.
   • If you have few enough machines, you could have a branch for each individual machine instead.
3. Create a branch for each piece of shared infrastructure, e.g. "modules/apache", "modules/cups", etc.
   • These branches are for holding files that are the same between all machines, like /etc/resolv.conf. These would be the files you keep in "svn:externals" repos now.

Building a New Machine

1. On a new machine, clone the git repo and check out the branch for that machine type.
   • I make this a read-only clone to prevent people from committing changes from production machines without testing.
2. Set up a cron job to automatically git pull the repo every day.

Changing Machine Branches

Changing the code in a single machine branch is simple; just git checkout the appropriate branch in your development environment, make the changes, and commit them back to the central repo. All machines in that branch will automatically get the changes the next time the cron job runs.

Changing Module Branches

Changing the code for a module branch is only slightly more tricky, as it involves two steps:

1. git checkout the appropriate module branch
2. Make your changes and commit them to the centralized server.
3. git checkout each machine branch which uses that module branch, and then merge the module branch into it. git will figure out that you've merged that module branch before and only notice the changes that have happened since that last common parent.

This method has both benefits and drawbacks. One benefit is that I can make a change to a module branch and apply it to the machine branches that need it, which letting the machine branches that don't stay with the older version until they're ready. The drawback, then, is that you have to remember to merge your module branch into each machine branch that might be using it. I use a script that traverses the commit tree and automatically does this merging for me, but can still be a pain.

As an alternative, newer versions of git support something called "submodules":

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.

This would allow you to build something a little bit like "svn:externals" trees, which you could then update in much the same way as you do now.