On Sat, Mar 7, 2015 at 11:57 PM, Rajesh Kumar <Rajesh.Kumar_at_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
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
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.
> Donâ€™t Miss FOCUS 2015 Orlando â€“ over 100 customer-led sessions and 1
> Grammy-winning singer! Learn More >
Received on 2015-03-08 09:37:54 CET