How to Export Code from Subversion Repo and Disable SVN?
772
A subversion repo was created on our Linux hosting server and it now needs to be removed. How do I identify the repo, export the codebase from it, and remove the repo and subversion functionality?
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.
Identifying the repository
What method do you use to access the repo? If it's
svnserve
, then look forsvnserve.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 usingfile://
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 runsvnadmin dump
orsvnadmin 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.