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?
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
> 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.
Received on 2015-03-08 17:40:48 CET