[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-committers] Installing SVN
|
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.