Grant Rettke <grettke@acm.org> writes:
> 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).
There are many, many commercial users of Subversion, some are
CollabNet's customers and some aren't. See
http://www.vsoft-tech.com.au/Default.aspx?tabid=77&EntryID=190
for some loose stats (I got that from Ted Dennison's posts on the
users@ list recently).
> 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.
I agree. The problem with obliterate is that it's hard to spec, and
it may be hard to implement some aspects of it as well. My estimate
is that if someone could put up appx $10k (US) to hire a Subversion
developer to start the discussion, follow it through, and implement
it, then 'svn obliterate' will happen. Without that, it will probably
still happen eventually, just not nearly as soon.
-Karl
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 18:48:10 2006