Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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)?

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 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

Back to the top