There exists a piece of software called CVS. It’s very handy for keeping track of files across multiple computers. So if you edit a file on computer A and want to edit it again on computer B, it is a way of making sure you have the most recent version everywhere. Also, if you keep the main data store on a remote server, it’s also a way to do network backups. The only problem with it is that it completely sucks.
Fortunately, somebody wrote a new system called Subversion, or svn for short. There are a lot of different ways to migrate from CVS to svn, but I went the slacker route. I had some, um, glitches. To spare you my pain, here’s a slacker howto:
Moving the Repo
mkdir ~/tmp cd ~/tmp cvs -d [path to repository] export -D now [name of respository]
Ok, while that’s going, let’s think about where you want to stick your svn repositories. I stuck mine in ~/svn/[name of repsitory]. Every one gets it’s own directory, no sharing like you can with CVS. I tried sharing and I had a disaster, alas. Anyway, let’s say you’re logged in to the machine where you’re going to host your repositories, and, for purposes of this example, your repo is named “Documents.” You’ve got it exported from CVS and sitting in ~/tmp/Documents/
Ok, part of the reason that CVS sucks is because it’s so damn hard to move things around or delete them. Well, go to town! Now you can! Once you get everything looking lovely, create yourself a svn repository and put your data in it.
mkdir ~/svn/Documents svnadmin create ~/svn/Documents/ svn import Documents file://[full path to your homedir]/svnrepos/Documents/ -m "Initial copy"
Ok, where that says, full path, it means what you get when you type: “cd; pwd” (without the quotes). If you type that, make sure to go back to our working directory: “cd ~/tmp”
Getting Client Machines up to speed
Ok, you have two options. One is to just blow away the repository that you have checked out of CVS and check out the new one from svn. Boom! You’re done! However, if you’re using this as a backup strategy, you probably haven’t backed up every file. For me, that doesn’t mean that I don’t like the file and want to keep it around. It just means that I can regenerate it or I can live without it. Not because I want to, but . . .. I have a bunch of files that I don’t want to lose, but not so much that I stuck them in the repository. Which leads to the second option.
Remember, slacker means brute forcing. If you have a million client machines and not, like, 1 or 2, you’re going to want to write a script. But if you’re lazy and only have a few machines, it can be faster to do it by hand.
So when your were busily beautifying your directory tree: moving, renaming, etc? Do that to your version on the client machines.
Now, get rid of all those stupid CVS folder. This is easy. Cd into the root directory of the repository. Type “rm -rf `find . -name CVS`”. But don’t take my word for that. First try “echo `find . -name CVS` | less” and make sure you’re listing the directories that you actually want to delete. (Obviously, skip the double quotes, but keep those weird backwards single quotes.)
Create a temporary directory on your client machine and check out a copy of your new repo there
mkdir ~/tmp cd ~/tmp svn co svn+ssh://[network host]/[path to repository] Documents
Ok, there’s like a million ways to access a svn repo, but that’s the best one. Ask your sysadmin to set it up.
Now, this is the fun part. Let’s call the CVS repo A and let’s call the new one B. There are files that are in B that are not in A and vice versa. Copy all the files that are in B but not in A into A. This includes a bunch of .ssh directories. One in every folder. If there are files in B that you would rather have than the version in A, then copy those too.
Wasn’t that fun? Now do it for all your client machines. Ok, there is now an issue of files in your checkout versions that differ from the ones in your repository. So go to you client machines and do some checkins.