> From: Michael Price [mailto:mprice@atl.lmco.com]
>
> Garrett Rooney writes:
> > On Fri, Aug 23, 2002 at 09:46:34AM -0500, Darrin Thompson wrote:
> > > Suppose that I as a subversion user accidentally checked into a
> "public"
> > > subversion repo some piece of private info. I would need to get
that
> > > information back out. Is it possible to do this using the latest
> > > subversion release? If it is possible, I'd love to hear the nitty
> details.
> >
> > that would be the hypothetical 'svn obliterate' feature, which does
> > not currently exist. it's a post-1.0 feature that people have
> > requested, but it's a fairly large amount of work to add. until
then,
> > it's one of those "doctor doctor, it hurts if i do this" "well,
then
> > don't do that" kind of things...
>
> Assuming someone was crazy enough to want to try and add such a
feature,
> what problems would he encounter along the way? If this has already
been
> outlined in a previous thread then a pointer to that discussion would
be
> most appreciated.
>
No problems as such. It's just a bunch of tedious work. If memory serves
the existing BDB schema makes it more expensive than it might be with a
real SQL data store. (due to not having more indices of the data)
> I must be a little more human than the rest of the subversion users as
I
> make quite a few mistakes and have longed for such a feature on more
than
> one occasion.
>
Being human is ok. However, obliterate is so expensive and resource
sucking on the repository that you only want to use it for very very
very important reasons, and not on a day to day basis.
Sample examples of valid uses of obliterate:
* Result of a court order
* Confidential information that needs to be completely removed
* Other very very bad things
Committing something you didn't want mean to commit isn't a decent
excuse for using obliterate. Obliterate is so expensive that it's like
to be an administrator only available option. (i.e. svnadmin)
Another additional reason for obliterate being handy is the when you
have lots of large binary rebuildable files that you want to remove
incremental versions of between given repository revision numbers in
order to save large amounts of disk space.
Hopefully, this isn't as necessary with Subversion's ability to do
binary deltas, but I do know that SourceDepot (MS's NT source code
control system that was described in some Usenix paper someplace) has
such a feature.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 23 17:59:33 2002