[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:19:13 CEST

Based on this thread, it seems like commits of unauthorized
material is a very real issue, but the issue is different for
different folks. Perhaps there ought to be a single thread that
document folks use cases for what they need in 'svn obliterate'.

Quoting Folker Schamel <schamel23@spinor.com>:

> Nik Clayton wrote:
>> John Peacock wrote:
>>> Nik Clayton wrote:
>>>> 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.
>>> You should also realize that if you use cvs2svn to convert your CVS
>>> repository,
>>> that generates a Subversion dumpfile as part of its processing. You
>>> can use
>>> svndumpfilter on that file to eliminate all of the paths that should
>>> go missing
>>> before you load it into a Subversion repo...
>> Right -- but that's for the one time import. I'm more concerned about
>> events that happen after that.
>> To paraphrase from a real-world FreeBSD example (names changed).
>> We had a committer who was employed by a US company that uses FreeBSD.
>> That company was developing some updates to FreeBSD code. The company
>> wanted to use that code in its next product release, and, some time
>> later, donate this proprietry code back to FreeBSD under the BSD license.
>> This committer inadvertently committed this code back to the FreeBSD
>> tree. This code consisted of some new files, and some changes to
>> existing source code.
>> Within minutes this code, which we were not licensed to distribute, was
>> mirrored to other CVS servers around the world (there are 162 of them at
>> the moment).
>> A few hours later (after being woken up at unfriendly time of the
>> morning), one of the master repository managers directly edited the
>> underlying ,v files -- the new files were completely removed, the
>> modified files were reset so that not only did the commit never happen,
>> there was no trace of the commit ever happening.
> You want "svn obliterate" to not work on per-file basis,
> but on per-commit basis?
> What should "svn obliterate" do if a later regular commit
> affects the same file as the inadvertent commit?
> Cheers,
> Folker
>> Because of the way CVS works, these changes could then be propogated to
>> the other mirrors, and integrated directly in to the ,v files, with no
>> changes to (or notification required to) the mirrors.
>> Big US company is happy, and stops threatening us with lawyers.
>> I need a way to solve that problem, quickly, should it ever happen again
>> if FreeBSD moves to Subversion.
> ---------------------------------------------------------------------
> 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:19:30 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.