[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-committers] Installing SVN
|
Karl,
Why don't you send those issues to Subversion mailing list or even
create bug reports/enhancement requests for Subversion? Some of that
might be already supported in SVN somehow, eg. for the last one you
should be able to install a post commit hook and get your line count
from there (but then line count doesn't mean much).
regards,
Eugene
Karl Matthias wrote:
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
