|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 cheersKarl
Back to the top