Deletion of earlier versions of Subversion

deletion of earlier versions of Subversion Key Words: Subversion

There was a problem with a recent version Management Server that had insufficient hard disk space. The result is that one version of the library has 47G, which occupies most of the server's hard disk space. After consulting with the company that you are using, you decide to reduce the version library size by removing the early resumes of the version library.
The specific job process is as follows:
Preparatory work
Stop the Apache server and modify the version library directory path permissions to root to prevent all users from using the version library. Restart Apache, which will ensure that users of other versions of the library continue to use it. Back up the original version library. Version Library full backup can take the svnadmin dump and Svnadmin hotcopy two ways. Both methods will be used throughout the process. First, as a full version of the library backup, in case of future job errors can immediately restore the original version of the library operation, recommend the use of Svnadmin hotcopy. On the one hand, the backup speed is faster, on the other hand the result of the backup is a can immediately use the version of the library, in need of recovery when the direct copy back on the line. The specific commands are as follows: Svnadmin hotcopy--clean-logs/path/to/repo/hotcopy >hotcopy.log 2>hotcopy_err.log &
The result of the backup is a directory, the same size as the original library, 47G.
The version of the dump version library that needs to be retained. The Svnlook Youngest/path/to/repo command allows you to see the final version of the version library. The version library I want to work on is 14079. After consulting with the other company, decide to keep the version between 10000 and 14079. So you need to dump the 10000 version from the version library. Specific orders are as follows
Svnadmin dump/path/to/repo-r 10000:14079 > Repo_dump_10000-14079.dmp 2>repo_dump_10000-14079.log &
Dump out of the file about 34G.
Check the log file to make sure the desired version is properly dump.
Rebuild Version Library Rm-rf/path/to/repo
Svnadmin Create/path/to/repo
Note that the--fs-type BDB parameter is not used in this, so the created version library is Fsfs backend. The following will continue to explain why this is done.
Re-import a new version
Svnadmin Load/path/to/repo < repo_dump_10000-14079.dmp > Repo_load.log 2>repo_load_err.log &
Check the log file to see if the load is successful. Use the Svnlook command to see the latest version of the library after load.
Modify version library permissions Chown-r Apache:apache/path/to/repo
This concludes the history version of the Repository. It should be noted that the latest version of the new version library should be 4080. In addition, after observation, the newly created version size is only 2.7G. This result once made me wonder if the load was unsuccessful. But that's actually true. What needs to be explained is that the original version of the library that accounted for 47G is BDB format. I also tried to create a bdb back-end version of the library, in the same way to guide the dump file, the resulting version of the library size close to 30G. And the speed of the import is significantly slower than the import to the Fsfs back-end version library. It's about one hours more. Visible BDB back-end and Fsfs back-end version libraries in some cases the size gap is surprisingly large. The manual is although also said Fsfs will be smaller than the BDB, but never thought it would be small so much. Subversion now has a reason to push the FSFS format. But I always feel that after all, BDB history is older and more stable. So in the future on the premise of hard disk space, I still prefer to use the BDB back-end format.