Re: [eclipse.org-committers] Installing SVN

[Karl Matthias <karl.matthias@xxxxxxxxxxx>]

Ok, I was keeping out of it, but since Denis hinted at it... I can't 
stop. :)  As Denis hinted earlier, we administrators despise SVN, no 
offense intended to anyone on the Subversive team.  People will use SVN, 
at the Foundation and otherwise, and so we need that integration in 
Eclipse and I'm glad we have options.  So far I've been mostly (but not 
always) happy with the Eclipse tooling for SVN.  But SVN from the 
administrative side has numerous deficiencies.  Sorry if this sounds 
like a rant, but someone has to say it. :)

The main administrative problems with SVN stem from 1)the monolithic 
database it maintains and 2)the fact that files can never be removed 
from the repository permanently.

Using a monolithic database system rather than the filesystem (you know, 
the thing everyone else uses to store files) mean we can't leverage the 
granular controls we already have in place (Unix groups) to control 
access to repositories.  We could use some SVN tooling to implement 
somewhat tighter controls, but it would be a complete duplication of a 
system we already maintain.  This is the smaller of the two problems.  
The larger one is that when something becomes corrupted (happens too 
often, unfortunately), you lose the whole repository.  Then we have to 
restore the whole repository either from a nightly mirror (hopefully), 
or from tape, which can be very slow.  Committers are then forced to 
re-commit any changes that happened that day.  That's harder than you 
would think because the client thinks it's in sync already, which means 
you have to check the code out from the restored repository, manually 
copy the files over and re-commit.  The repository is down during this 
whole process.  With CVS you can restore files on an individual basis 
and one corrupted file (almost never happens) rarely causes a problem 
with anything else.  Restores take seconds because you don't have to 
load megs of data from tape.  Copying the repositories is slow because 
the fact that the files are very large makes rsync less helpful since it 
diffs whole files.  It wastes a lot of time and local bandwidth.

And, with SVN, old revisions are always kept.  This might be good in 
some ways, but mostly it's problematic.  The effect is that when someone 
checks in something that violates IP cleanliness rules or that was just 
plain wrong, we have to dump the whole repository, filter the text file 
with the SVN tools, and reload it.  This is slow and error prone.  The 
repository is unusable while we do that, and something fairly often 
breaks in the tooling while doing this (ask the Technology people), with 
the not unlikely possibility of toasting the repository and having to 
try again.

A third and more minor, but still very annoying issue, is that SVN does 
not log LOC counts for commits.  That means we can't track that for 
project Dash without doing a diff of every change and counting the lines 
of code.  That's an absurd use of resources, so we don't do it.  There 
are a couple of SVN stats packages that do this, but that's how they do 
it, too.  CVS just reports it the commit message because, well, it 
already has to deal with the file, so why not log it then?

Now, I don't do large branches and merges, so I can't speak to that from 
a user perspective, but in case you want to know how it feels to admin 
SVN, there you have it. :)  Thanks for listening and cheers

Karl


Schaefer, Doug wrote:
> BTW, I think it's a combination of SVN and the clients. The biggest 
> problem for me was merge which I think is both. And I saw the same 
> issues someone mentioned earlier with refactoring. The client got 
> totally lost. I love the promise of tracking file movements and 
> renames, but the clients need to be rock solid for me to trust them. 
> And that includes easy to install.