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
probably
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