On Sun, Mar 8, 2015 at 12:42 PM, Branko Čibej <brane_at_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.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!",
>
> 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.
Received on 2015-03-09 02:27:48 CET