On Sat, Mar 7, 2015 at 11:57 PM, Rajesh Kumar <rajesh.ku...@jda.com> wrote: > I have one Huge SVN repos which is around 1TB in terms of size. I have two > requirement as follows and i would like to know the best approach to be > followed to save time and effort.
According to the doctrine of "there shall be no obliterate command, the record must be kept absolutely pristine at all costs, praise the gospel of all history matters!", you don't In theory, history is kept pristine and cannot be discarded. Sometimes there are even good historical or legal reasons to do so. Personally, I consider it like "cleaning your plate". It's a good idea when you're 5 years old, because your folks want you to eat your vegetables instead of candy later and they know better than you that you *will* get hungry again quite soon. But for grownups, with the big pile of starchy empty content from abandoned branches, and fatty binaries that will just clog your backups and your workflow and give you a coronary when you realize *how much* cruft is in the failover backup system, I find it OK to say "no: we've had enough history" and send some of it to the wastebasket. In practice, when your repository has reached a full Terabyte, it's out of hand and has probably wound up cluttered with unnecessary binary content, such as jar files, rpm's, or iso images. If it's where you keep a year of binary releases of a big project, OK, but otherwise, I think not. > 1. Duplicating the whole repos of 1TB in shorter span of time and create > another SVN repos. This is straightforward and usually the way to do it if you're in a rush. > 2. How to reduce the Repos size drastically without impacting the > integrity and version of the files? Here my repos size is 1TB and i want to > make it smaller without deleting any files? what are the ways of doing > so.....? You can't reduce it much without cutting out history. You *can* set a final tag, do an export of *that*, and import that to a new repository, or dump the tag and load it as the trunk of a much, much smaller new reporisoty, and *lock the old repository permamenently", and *make people check out new clean working copies from the new repository*. I've done that very effectively in a number of professional environments, when individual products could and should have been forked off to sepaqrate repositories. > -Rajesh > > Don’t Miss FOCUS 2015 Orlando – over 100 customer-led sessions and 1 > Grammy-winning singer! Learn More >
