subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stümpfig, Thomas <>
Subject RE: Copy and Reduce the size of SVn repos
Date Wed, 11 Mar 2015 07:00:04 GMT
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.


-----Original Message-----
From: Les Mikesell []
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 <> 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
> 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
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
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry Software Management
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; Registergericht:
Amtsgericht Köln, HRB 70858
View raw message