On Mon, 18 Sep 2006, Grant Rettke wrote:
> If commercial users really want 'svn obliterate', they would pay for it.
The architectural quirk in CVS (and I say "quirk" because it does not seem
like it was an intentional design goal for CVS) that allowed Nik to deal
with his late night IP emergency is something that we've heard other
customers note while evaluating a move, and is especially relevant in
non-Open-Source networks involving a lot more complicated scenarios of who
can be trusted with what.
But I have not heard of it being the sole reason why one of our customers
or prospects decided against the move from CVS to SVN, nor from any other
SCM tool. That's why CollabNet's not focused on it at the moment, and
instead on things like merge tracking and overall performance & quality.
It does have a sort of stuffing-the-genie-back-in-the-bottle feel to it.
Commits usually trigger emails, and you can't recall those emails.
Backups kept by a mirror will have that content.
Nik, I don't mean to discount your desire for this feature, but it might
be useful to ask whether there are ways to mitigate the need for it. One
thing we suggest to customers who note this and want the same thing is to
encourage them to use lots of small individual repositories based on
modules/projects/whatever rather than one single big one. That way,
needing to do a dump/svnfilter/load cycle can be much shorter, and you
don't need to take the repo down for every other team, and svn:externals
helps make it mostly seamless for the average end user. The downside is a
lack of transactional consistancy for changes that span repositories, but
such changes suggest a lack of proper modularity anyways. It doesn't
answer the what-about-mirrors question either.
If this kind of thing happened at Apache while we were using CVS, I think
we would have responded in the same way as Nik did. If it were to happen
today, with all of Apache's repositories now under SVN, I think we would
make the call between either saying "too bad - the company and the
developer need to figure out the right way to atone for this", or if the
developer's job really was at risk, taking the repository down for days
while doing a conversion and then instructing the mirrors to do a clean
re-mirroring. That's painful but still far less than the pain of sticking
to CVS would have been. It's also not clear that the story would be any
different for any other VC system, except those whose repository data
model looks like CVS's - a model that prevents transactions, versioning of
directories, efficient tagging, etc etc.
Brian
---------------------------------------------------------------------
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:45:38 2006