[#2968] dbm/gdbm/sdbm etc — Dave Thomas <dave@...>
Does ext/dbm supersede gdbm and sdbm?
7 messages
2004/06/07
[#2977] Enumerable#each_with_index in "ri" — Johan Holmberg <holmberg@...>
11 messages
2004/06/12
[#3132] Reporting RI-documentation corrections ?
— Johan Holmberg <holmberg@...>
2004/07/05
[#3133] Re: Reporting RI-documentation corrections ?
— Dave Thomas <dave@...>
2004/07/05
[#3135] Re: Reporting RI-documentation corrections ?
— Austin Ziegler <halostatue@...>
2004/07/05
Speaking of ri documentation, is there anywhere that documents the
[#2978] Date.from_time — Gavin Sinclair <gsinclair@...>
Folks,
5 messages
2004/06/13
[#2982] Array#shift(n) — Michal Rokos <michal@...>
Hello,
15 messages
2004/06/14
[#2985] Re: [Patch] Array#shift(n)
— nobu.nokada@...
2004/06/14
Hi,
[#2987] Re: [Patch] Array#shift(n)
— matz@... (Yukihiro Matsumoto)
2004/06/14
Hi,
[#2988] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/14
On Monday 14 of June 2004 16:13, Yukihiro Matsumoto wrote:
[#2989] Re: [Patch] Array#shift(n)
— matz@... (Yukihiro Matsumoto)
2004/06/14
Hi,
[#2991] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/14
Hello,
[#2998] Re: [Patch] Array#shift(n)
— nobu.nokada@...
2004/06/15
Hi,
[#2999] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/15
Hello,
[#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!
[#3010] Re: CVS repository
— Elliott Hughes <ehughes@...>
2004/06/16
On Wed, 2004-06-16 at 09:45, Michal Rokos wrote:
[#3011] Re: CVS repository
— ts <decoux@...>
2004/06/16
>>>>> "M" == Michal Rokos <michal@ruby-lang.org> writes:
[#3012] Re: CVS repository
— "Eugene Scripnik" <hoaz@...>
2004/06/16
Hello.
[#3027] rb_mod_freeze??? — Michal Rokos <michal@...>
Hello!
5 messages
2004/06/17
[#3047] Move all stack info to gc.c — Michal Rokos <michal@...>
Hello,
13 messages
2004/06/23
[#3049] Re: [Patch] Move all stack info to gc.c
— matz@... (Yukihiro Matsumoto)
2004/06/23
Hi,
[#3057] Ruby 1.8.2 to be released. — matz@... (Yukihiro Matsumoto)
Hi,
20 messages
2004/06/23
[#3060] Re: Ruby 1.8.2 to be released.
— Hugh Sasse Staff Elec Eng <hgs@...>
2004/06/23
On Thu, 24 Jun 2004, Yukihiro Matsumoto wrote:
[#3063] Re: Ruby 1.8.2 to be released.
— matz@... (Yukihiro Matsumoto)
2004/06/23
Hi,
[#3090] class= and type checks when casting — "Sean O'Dell" <sean@...>
Matz, I'm not sure if you followed the discussion in ruby-talk about having a
6 messages
2004/06/25
[#3095] 1.8.2: Segfault — Elven <elven@...>
6 messages
2004/06/26
[#3102] gdbm abort - OSX — Dave Thomas <dave@...>
Just before I start another debugging session, has anyone seen this, or
7 messages
2004/06/27
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