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