[#3006] CVS repository — "Eugene Scripnik" <hoaz@...>

Hello.

21 messages 2004/06/16
[#3008] Re: CVS repository — ts <decoux@...> 2004/06/16

>>>>> "E" == Eugene Scripnik <hoaz@gala.net> writes:

[#3009] Re: CVS repository — Michal Rokos <michal@...> 2004/06/16

Hi!

[#3057] Ruby 1.8.2 to be released. — matz@... (Yukihiro Matsumoto)

Hi,

20 messages 2004/06/23

Re: CVS repository

From: "Sean E. Russell" <ser@...>
Date: 2004-06-17 13:18:23 UTC
List: ruby-core #3034
On Wednesday 16 June 2004 18:44, Dave Thomas wrote:
> I'm interested in this statement (as the need to maintain the
> repository is the reason I don't recommend SVN to clients right now. Am
> I wrong in my belief that SVN requires more server-side maintenance
> that CVS?

In my experience, SVN requires much less administration than CVS.  I've been 
running a Subversion repository on Germane-Software since before 2002, and 
the only time administration has ever been required was when upgrading to new 
versions of Subversion.

Roberch Church followed up with:
> I'm with Dave here. SVN requires more maintenance than CVS. SVN requires 
> an occasional 'svnadmin recover' when something gets wedged. CVS, 
> having a stable and simple repository format, simply doesn't have this 
> issue.

While Subversion was in "beta", the developers occasionally changed the 
database format; this would require a database dump and reload, which was 
pretty easy.  Seriously; in the past three years I've never had a problem 
with a Subversion repository getting "wedged".  The only problems I've ever 
had were because of admin mistakes, like forgetting to dump the database 
before an upgrade.

I really take issue with the statement that CVS doesn't have "this issue".  
I've never seen a CVS repository that didn't require regular attention to do 
things like remove lock files.  Heaven forbid anybody would want to do 
something as complex as *rename* a file, and moving directories was a hideous 
experience -- both require administrative attention to accomplish.  And as 
you mention -- woe betide you if anything happened to the network connection 
while you were trying to commit, and left the repository in a munged state. 

> CVS can also be backed up by simply tarring the repository. SVN requires 
> specialized tools for that.

Huh?  No, you can simply tar the repository directory.  However, doing a dump 
of the database is a better solution.  I'm not sure why you object to using 
"specialized tools" --- that "specialized" tool you're talking about is 
"svnadmin dump" --- are you expecting to host a Subversion repository on a 
machine that you don't have Subversion installed on?

> I use and prefer SVN, but it *is* slightly more cumbersome to maintain. 

Your experience has been different from mine.  I used and maintained CVS 
repositories from 1994 to 2000, when I started using Subversion, and in my 
experience, Subversion has been much more hands off.  In fact, at 
GlaxoSmithKlein they're *still* using a Subversion server that I set up for 
them two years ago... I haven't worked there for five months.  There is 
nobody administering the repositories it services, and there were five of 
them, each with multiple projects serving a development community of fifteen 
to twenty developers.

> I often wish the developers had read Dave's book, the part about the 
> potency of plain text in particular.

The Subversion team's decision to use a database was, IMO, the best decision 
they made.  Speed, compactness, and -- above all -- the ability to make the 
SCC system ACID were well worth the effort.  However, this is way off topic.

-- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

In This Thread

Prev Next