Downgrading svn repositories from 1.5 to 1.4

It's an odd situation, but occasionally you need to convert your data to run on an older version of an application rather than the typical upgrade to newer versions. One such situation arose for me recently. I was starting a new project and was beginning to add/change code while working from home after-hours, with obviously no server admins around to IM a request for a new subversion repository. Being the agile developer I am, I figured I'd just create a local repository and upload it when I was next at the office.

As you may know, practice rarely follows theory. The theory was that I'd just do an svnadmin dump to create a data dump of my local repository and then svnadmin load to get it onto the main svn server at work. As it turned out, I forgot to check something. You see, the svn server uses v1.4 while I've been running v1.5 for about eight months, since shortly after it was first released - as a result, after several days of development my fresh 1.5 data dump wouldn't work with the server's v1.4. Bummer. I submitted a request for the IT department to upgrade the servers to 1.5 - there are several good reasons to do the upgrade - but it isn't something that's going to happen too quickly due to the need to then have all of the other users upgrade their clients.

Thinking I was going to be stuck for a while keeping my repository locally, I kept working locally and figured I'd be able to just wait the few weeks until the central upgrade. Again, life never works quite like you think it will, and I suddenly immediately needed to be able to upload my work to a staging server. Within an hour of dealing with SFTPing files to the server, trying to ensure two different instances of the servers were kept up-to-date and concurrent, the horrors of Life Before Revision Management came flooding back to me and in a mad panic I set out to get my code into a repository one way or another.

This is where my current web hosting provider, Dreamhost, saved my sanity. I had previously set up a repository on my account for some personal code development so figured I'd repeat my success there with the new project, as it would at least be accessible remotely. A couple of quick minutes had an svn dump of the repository waiting on the server for me to import into a new repository. Except it didn't want to work, it turned out that even Dreamhost was using the older v1.4. Argh! It seemed I was doomed to fail!

It was around now I thought "why don't I RTFM?" A quick look at "svnadmin help dump" didn't turn up anything, ditto for "svnadmin help load". Then I tried "svnadmin help create" and saw the previously unknown (to me) option "--pre-1.5-compatible" which is described as "use format compatible with Subversion versions earlier than 1.5" - a step in the right direction! This option would allow me to create a local repository in my local v1.5 setup which would then be compatible with v1.4. I guessed that it might then also create a dump file compatible with v1.4, which could then be cleanly imported into a new v1.4 repository... and sure enough it worked!

So, the exact steps I took were:

• Created a dump of the v1.5 repository named myproject_1_5.dump using the command "svnadmin dump myproject > myproject_1_5.dump".
• Created a new repository that was compatible with v1.4 using the command "svnadmin create --pre-1.5-compatible myproject2".
• Imported the v1.5 dump file into the new myproject2 with the command "svnadmin load myproject2 < myproject_1_5.dump"
• Created a dump of the v1.4 repository named myproject_1_4.dump using the command "svnadmin dump > myproject_1_4.dump".
• Uploaded project_1_4.dump to the hosting account.
• Created a new repository: svnadmin create myproject
• Loaded the new data dump: svnadmin load myproject < myproject_1_4.dump".

Then, after a few quick moments (it was only up to rev 103 at this point) I was finally able to get back to development using a centrally accessible repository for a few days until I'm back at the office again and can get it back onto company territory.

NOTE: Yes, I know that git would probably have worked better in this situation, but the company is not currently ready for that move..