1 Answer
1

Identifying the repository

What method do you use to access the repo? If it's svnserve, then look for svnserve.conf, the path to the repository will be inside. If it's HTTP/HTTPS, then look into your web server configuration file. If you access it using file:// protocol, then I'm afraid you'll have to figure its location by yourself ;).

Exporting the data

Stop the server used to give access to the repository and make sure no one is using it locally (via file://). You don't want to miss some last-second update to the code. Then you can run svnadmin dump or svnadmin hotcopy, whichever you prefer, to have a ready-to-move set of data files. Additionally, save the files responsible for authentication to the repository. You may want to re-create corresponding access hierarchy in the new location, or simply know in 2 years, what users had access to which parts of code.

If, for reasons incomprehensible, you want to drop the history of the project(s) within the repo, then simply check out the latest version(s) of project(s) and forget you've ever been using a version management system.

Removing the repository and Subversion

After you migrated the data off the server being decommissioned (at least 2 independent data copies recommended), and, preferably, have it imported into their new home (to verify that you can actually use whatever you exported) you can remove binaries used by it. It means the subversion packages plus whatever was used to access the repository. If you use svnserve, then you can simply remove it, using standard procedures for your distribution. For HTTP/HTTPS based access you need to remove modules responsible for Subversion interface, but may as well mean removing the whole server (if its sole role was to let developers access the code). If the web server stays, then remember to comment out/remove section of the configuration, that was responsible for interfacing the server with Subversion.

The last step is a simple rm -rf on the Subversion repository directory.