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.
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.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 10:54:50 2006