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

Re: Issues 516: "svn obliterate"

From: Grant Rettke <grettke_at_acm.org>
Date: 2006-09-18 16:28:17 CEST

Subversion's features are really driven by its customers. Right now,
there are two groups customers: Collab.net's customers and the open source
customers of Subversion (GCC seems to be a big one).

If commercial users really want 'svn obliterate', they would pay for it.

If open source users really want 'svn obliterate', it would come about
as the result of a lawsuit or something.

Based on both the bugzilla entry and emails in this group, it sounds
like 'svn obliterate' is non-trivial both from an implementation and
use-case perspective.

Quoting Nik Clayton <nik@ngo.org.uk>:

> Hi,
> Is anyone actively working on implementing an API to completely
> remove a file from a repository, as described in:
> http://subversion.tigris.org/issues/show_bug.cgi?id=516
> ?
> I'm looking at what would be involved in migrating FreeBSD from CVS
> to Subversion, and we think we need this functionality.
> As well as the traditional "Someone's committed a core file by
> accident" use case that's covered in that issue, we have another use
> case that doesn't seem to have been discussed (at least, a quick
> search didn't turn it up).
> This is where a committer inadvertently commits code that they are
> not licensed to commit. This might be a binary blob from a third
> party vendor that's not supposed to be distributed, or it might be,
> as has happened to FreeBSD, been code being developed for a
> commercial third party, that will eventually be open sourced, but
> that is not supposed to be open sourced yet.
> That's happened to FreeBSD. Some emergency CVS repo surgery meant
> that the offending code was removed from the master repo, and all the
> mirrors shortly caught up.
> I don't (yet) have a solution that will work with Subversion. I'm
> aware that it's possible to dump the repo from just before and just
> after the commit, load the first dump, manufacture a dummy commit,
> and then load the second dump.
> However, I don't yet know how feasible that is. First, the dump/load
> cycle for a large repository is lengthy -- doing this to a
> hypothetical FreeBSD SVN repo, which will contain 10+ years of
> imported CVS history is likely to be prohibitively so. Second, I
> haven't tested what the effects of this procedure would be on any one
> who has mirrored the repo (using svnsync) or has a working copy that
> contains the offending item.
> Alternative approaches, such as restore from a backup prior to the
> commit, and replay the remaining commits are also possible, but
> again, I've yet to investigate what sort of effect this would have on
> mirrors that are svnsync(1)'ing the repo.
> Hence our interest in supported command/API that does this.
> N
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 16:28:31 2006

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

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