info-cvs
[Top][All Lists]
Advanced

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

RE: Future CVS Development


From: Greg A. Woods
Subject: RE: Future CVS Development
Date: Tue, 19 Jun 2001 04:31:05 -0400 (EDT)

[ On Monday, June 18, 2001 at 23:35:09 (-0700), Kostur, Andre wrote: ]
> Subject: RE: Future CVS Development
>
> Mr. Woods, If you read back in the topic, you'll see at the end of my
> original message I distinctly mentioned calm, reasoned debate.  So far I've
> seen mostly knee-jerk reactions.

My reaction is most definitely not a "knee-jerk reaction".  It is
plainly clear right from the very origins of CVS that it was designed to
do ONLY as it's name implies, i.e. to be a CONCURRENT Versioning System!

If you read back in the vast and lengthy archives of this forum you'll
find that only someone expecting to invoke a passionate debate would
ever even dream of asking for a "calm, reasoned debate" about such a
nonsensical issue!

> Note that the core philosophy is that multiple edits is fine since merging
> is reliable.

Actually if you read the paper "CVS II:  Parallelizing Software
Development" by Brian Berliner you'll find that this is not a "core
philosophy", or something that's considered "reliable", but rather
something that's been discovered to be relatively (and perhaps even
surprisingly) successful in a certain class of development environments.
If you go further to examine the scenarios in which CVS has been most
successfully used since then you'll find that the evidence only further
confirms Brian's original observations.  I.e. concurrent editing of
text-based source-code files is remarkably successful due to the normal
way in which ASCII text is used to represent program source code!

>  In general, this philosophy does not hold up in the case of
> binary, non-mergeable files.  (Wait, since it doesn't fit the "core desgin",
> shouldn't it be removed from CVS?)

Of course not.  CVS was not designed to handle unmergeable files.  Ergo
your argument is meaningless within its context.  RTFM.

Most importantly it's not even conceptually possible to a concurrent
versioning system on primarily non-mergable files -- the mere concept of
allowing concurrent editing assumes theres some way to mostly automate
the merging of concurrent changes in a logical manner -- something
that's impossible, by definition, for binary files.  RTFM.

> One thing I hope everyone can agree on is that the fossilization of the
> design of any program is generally not a good thing.  It will lead to the
> program no longer being used for the task as other, more capable programs
> take over for it.  If a program's destined to fail in this manner, why
> should users/developers invest any time in the program if it's destined to
> fail?

That's one of the most meaningless paragraphs I've ever read, even in
this forum.

Please find some other program to denigrate.  CVS is doing just fine as
it is and obviously does not need your "help".  It is not "destined to
fail".  It's not just going to stop being useful for the job it was
designed to do just because someone such as yourself says it should fail
because all of us who use it daily will not stop using (and supporting)
it just because you think it's incapable of doing something *YOU* want
it to do.

As I just mentioned in another somewhat related thread anyone and
everyone is "free" to design and implement a replacement for CVS.  If
such a thing actually succeeds in replacing CVS then that's an
achievment to be applauded.  In the mean time CVS does a fair job at
what it's been designed to do and there seems to be no shortage of
people who have requirements that it can specifically fill.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]