On Sun, Mar 8, 2015 at 12:42 PM, Branko Čibej <br...@wandisco.com> wrote: > On 08.03.2015 09:35, Nico Kadel-Garcia wrote: >> 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!", > > Heh, I have to ask, where did you find that doctrine? There's no such > thing. It's all a lot more mundane: First, you have to get people to
I've had to deal with that doctrine personally and professionally since first working with Subversion in 2006. It comes up again eveyr so often, for example in http://subversion.tigris.org/issues/show_bug.cgi?id=516 and is relevant to the original poster's request. There can be both software and legal reasons to ensure that the history is pristine and never forgets a single byte. But in most shops, for any lengthy project, *someone* is going to submit unnecessary bulky binaries, and *someone* is going to create spurious branches, tags, or other subdirectories that should go the way of the passenger pigeon. > agree what "obliterate" actually means; there are about five meanings > that I know of. And second, all five are insanely hard to implement with > our current repository design (just ask Julian, he spent about a year > trying to come up with a sane, moderately backwards-compatible solution). > > -- Brane I appreciate that it's been awkward. The only workable method method now is the sort of "svn export; svn import to new repo and discard old repo" that I described, or a potentially dangerous and often fragile dump, filter, and reload approach that preserves the original URL's for the repo, but it's really not the same repo. It remains messy as heck. This is, in fact, one of the places where git or other systems's more gracious exclusion or garbage collection tools doe better. Even CVS had the ability to simply delete a directory on the main fileserver to discard old debris: it's one of the risks of the more database based approach of Subversion to managing the entire repository history.
