[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Elliotte Rusty Harold gets it wrong

From: Talden <talden_at_gmail.com>
Date: 2007-10-09 21:52:15 CEST

> > > You're mistaken about SVN missing the feature to permanently delete
> > > ("obliterate") repository contents. It's just that it is not a user
> > > function. Rather, it is an administrator function -- available since
> > > version 1 at least. The repository administrator would use svndumpfilter
> > > to take a repository and filter out the bad commit(s) and pipe that into
> > > a new repository. You don't want to do this all the time because it takes
> > > skill and effort, but it's supposed to be a low occurence event. The
> > > absence of a user-level 'obliterate' function is considered a feature,
> > > not a bug by the svn developers.

> > Well, many of us consider the lack of a convenient 'obliterate' command
> > to be a bug, see http://subversion.tigris.org/issues/show_bug.cgi?id=516.
> > However, there's a workaround, and designing the feature would
> > actually be non-trivial, so we haven't done it yet.
> >
> > -Karl

> Thanks for the clarification and pointer Karl.
>
> Now that there is evident support for creating some obliterate command, I'm
> looking forward to the day when it's actively under development.
>
> I have to trim the size of my repository, because I simply do not care about
> what happened two or three years ago in my repository. I don't mind if that
> data is discarded or at least taken 'offline'. I'll be using svndumpfilter.

I wouldn't treat the missing Obliterate as a space-saver feature.
Unless you never use 'svn copy' (branching, tagging or just plain
forking a file) the repository is just as likely to get larger as it
is to get smaller. A situation where it might get smaller would be
the removal of an old project from which no content has been retained.
 However any situation where old content is removed but multiple
copies of that content are retained would likely produce a larger
repository as the initial revision of each retained file would be the
complete content rather than a cheap copy.

Much more important are:
- Removing recent erroneous commits for space (say someone checking in
a complete {NAME OF RDBMS WITH LARGE DISTRIBUTION HERE} distribution
image instead of just a JDBC driver).
- Removing content for privacy, security or licensing reasons.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 9 21:52:38 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.