Re: [eclipse.org-committers] Installing SVN

[David Whiteman <dlwhiteman@xxxxxxxxxx>]

So is SVN similar in architecture to ENVY (for those of you
that remember that system from VisualAge and Smalltalk)?

Karl Matthias <karl.matthias@xxxxxxxxxxx> wrote on 10/01/2008 12:38:38 PM:

> 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?


David
-- 
David Whiteman                          
mailto:dlwhiteman@xxxxxxxxxx