[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] cvs, servers and stuff.



"Carsten Haitzler (The Rasterman)" wrote:
> 
> 
> On Tue, 15 Aug 2006 18:34:57 -0400 Kevin Brosius <cobra@compuserve.com> babbled:
> 
> > Kim Woelders wrote:
> > >
> > >
> > >
> > > It seems to me that our SCM system feature requirements are extremely
> > > limited. We hardly ever tag or branch, let alone do merging between
> > > branches or anything resembling changeset management.
> > >
> > > I think CVS amply provides the features we need. It's simple and robust.
> > > It's far from perfect, but as Michael says - It's the devil we know.
> > >
> > > I don't believe changing SCM will make any significant difference to the
> > > problems that we appear to have, except possibly on a very short term.
> > > Even in the unlikely case that some SCM system is twice(four/ten/...
> > > times) as fast as CVS the problem we have will resurface if/when the
> > > user base grows accordingly.
> > >
> > > Unless there happens to be an SCM system that is just incredibly more
> > > efficient than CVS I also think that we would make a change for the
> > > wrong reason. Changing SCM system should IMO be done only if we
> > > want/need particular features not available in CVS.
> > >
> > > In the unfortunate case that it is concluded that we want to switch away
> > > from CVS I hope it will be to git. Not because I know it from personal
> > > experience, but simply because it is used by linux and xorg, which are
> > > two projects I respect.
> > >
> > > /Kim
> >
> > Well said Kim.
> >
> > I agree completely.  I'd like to see a multi-connection test of cvs vs
> > svn, but I also won't promise to set it up myself. :)  It was nice of
> > raster to open this debate, but we have running servers with cvs (and
> > webvc) and should really have a compelling reason to move.  As you can
> > see, I'm not much of a fan of change for change's sake. ;)
> 
> the compelling reason is that (apparently) anoncvs is straining under its load
> (again) and this happened so quickly that i am putting up a debate for
> alternate solutions - willing to discuss really anything :)

Hmmm. I'm not sure I see the logic that way.  We moved off sf to get the
ability to do rsync backup of cvs (one of the reasons, along with some
intermittent performance of dev and anon cvs.)  We now have solid dev
cvs performance, rsync access, and better anon access (IMO.)

Are you against requesting offers of open anon mirrors?  With the rsync
access, that seems easy, but of you want a anon cvs farm that has full
status monitoring, then you're stepping the complexity up a bit.

I guess I don't buy the 'straining under the load and happening quickly'
as a compelling reason. ;)  It's a different situation.

-- 
Kevin