On 08.03.2015 17:39, Andreas Stieger wrote: > Hello, > > On 08/03/15 05:57, Rajesh Kumar wrote: >> 2. How to reduce the Repos size drastically without impacting the >> integrity and version of the files? > Several points: > A. Are you talking about the on-server repository size or the size of a > working copy? The reasons one needs to ask are that many users regularly > confuse the terms, and that many will check out the root of the > repository into a working copy which unnecessarily increases the on-disk > size of a working copy by duplicating /branches and /tags. > > B. For the server on-disk size, ensure representation sharing is enabled > throughout the lifetime of the repository. When using deep tree > structures and large properties also enable "directory and property > storage reduction" available in 1.8. As these only take affect for added > data, you need to perform what is referred to as a dump-load cycle and > switch to the new but content-identical repository. Dump/load are > documented. > >> Here my repos size is 1TB and i want to make it smaller without >> deleting any files? > Whoa this is kind of what a scm is designed not to allow. And deleting > any files inside the repository tree does not reduce it's size as you of > course retain all history, including deleted items. > >> 1. Duplicating the whole repos of 1TB in shorter span of time and >> create another SVN repos. > You can perform a seamless migration to a second otherwise identical > repository with reduced size. First prepare a replacement offline while > keeping it up-to-date with the original by using svnsync configuration > as documented in the Subversion book. You will need some migration space > for that, can be on the same or another server. The repository URL may > or may not change in the course of that - if it does do take care that > you seamlessly direct users to the new data.
And it bears repeating: If you replace a repository, please make sure to restart Apache and/or svnserve to clear stale caches. -- Brane
