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
Received on Mon Sep 18 11:51:42 2006