Re: [eclipse.org-committers] Installing SVN
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?