So is SVN similar in architecture to
ENVY (for those of you that remember that system from VisualAge and Smalltalk)?
eclipse.org-committers-bounces@xxxxxxxxxxx wrote on
10/01/2008 12:38:38 PM:
> Ok, I was keeping out of it, but since Denis hinted at it... I can't
> stop. :) As Denis hinted earlier, we administrators despise
> offense intended to anyone on the Subversive team. People will
> 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
> always) happy with the Eclipse tooling for SVN. But SVN from
> administrative side has numerous deficiencies. Sorry if this
> 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
> the thing everyone else uses to store files) mean we can't leverage
> 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
> 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
> restore the whole repository either from a nightly mirror (hopefully),
> or from tape, which can be very slow. Committers are then forced
> re-commit any changes that happened that day. That's harder
> would think because the client thinks it's in sync already, which
> you have to check the code out from the restored repository, manually
> copy the files over and re-commit. The repository is down during
> whole process. With CVS you can restore files on an individual
> and one corrupted file (almost never happens) rarely causes a problem
> with anything else. Restores take seconds because you don't
> load megs of data from tape. Copying the repositories is slow
> the fact that the files are very large makes rsync less helpful since
> diffs whole files. It wastes a lot of time and local bandwidth.
> And, with SVN, old revisions are always kept. This might be
> some ways, but mostly it's problematic. The effect is that when
> checks in something that violates IP cleanliness rules or that was
> plain wrong, we have to dump the whole repository, filter the text
> with the SVN tools, and reload it. This is slow and error prone.
> repository is unusable while we do that, and something fairly often
> breaks in the tooling while doing this (ask the Technology people),
> the not unlikely possibility of toasting the repository and having
> try again.
> A third and more minor, but still very annoying issue, is that SVN
> not log LOC counts for commits. That means we can't track that
> project Dash without doing a diff of every change and counting the
> of code. That's an absurd use of resources, so we don't do it.
> are a couple of SVN stats packages that do this, but that's how they
> it, too. CVS just reports it the commit message because, well,
> 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
> 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