RE: Copy and Reduce the size of SVn repos

Hi all
Actually splitting projects is not a solution to something that eliminates old data. Think of a project with one file only. Legally one might be forced to keep the file at least for 5 or 10 Years. But after this period the very same old revisions of the file must be destroyed because of other legal or contractual obligations. There is enough reason for final deletion of old data. I appreciate very much the work of open source programmers. And as a matter of fact we deal with svn's limitations as we use it with much success for our purposes. Said this, one of the most wanted feature is obliteration.

Regards
Thomas

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Sent: Dienstag, 10. März 2015 23:37
To: Nico Kadel-Garcia
Cc: Branko Čibej; Subversion
Subject: Re: Copy and Reduce the size of SVn repos

On Sun, Mar 8, 2015 at 8:27 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> >>
>> 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.

Maybe it is time to change the request from 'obliterate' to _any_
reasonable way to fix a repository that has accumulated cruft. And a
big warning to new users to put separate projects in separate repositories from the start because they are too hard to untangle later. I've considered dumping ours and trying to split by project, but I'm not even sure that is possible because many were imported from CVS then subsequently moved to improve the layout. So I can't really filter by path.

--
   Les Mikesell
     lesmikesell_at_gmail.com
-----------------
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 70858