info-cvs
[Top][All Lists]
Advanced

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

Re: outsider's perspective


From: Donald Sharp
Subject: Re: outsider's perspective
Date: Tue, 27 May 2003 17:59:08 -0400
User-agent: Mutt/1.4i

On Tue, May 27, 2003 at 02:45:14PM -0700, Kaz Kylheku wrote:
> On Tue, 27 May 2003, Steve deRosier wrote:
> 
> > Also, if so many people NEED this functionality, why doesn't it get 
> > added to CVS? 
> 
> One reason is that it doesn't have to be literally added into the CVS
> program, but rather imposed on top of it. CVS can be used as a
> subprocess in a version control system that has the functionality.
> This is a legitimate way of creating a ``CVS II''. In fact, this
> approach is better in many ways than hacking inside CVS.  Separate
> processes provide fault isolation, and avoid forking the codebase. If
> ``CVS II'' has a bug that stems from CVS, you just upgrade CVS to the
> bugfixed version. It's blackbox inheritance! CVS gives us the ``base
> class'' which we ``override'' to the get ``CVS II'' behavior with
> versioned directories, symbolic links, permissions, etc.
> 
> There are a few drawbacks. The command line interface sometimes is less
> than ideal, and also systems impose limitations on its length, so the
> ``CVS II'' layer sometimes has to break up long command lines, turning
> one logical CVS operation into multiple actual ones.  Another problem
> is that the output of the CVS process sometimes has to be passed
> through a text filter so that it makes sense at the ``CVS II'' level.
> Doing the substitutions in CVS itself would mean altering its code.
> 
> ``CVS II'' has already been written, and released almost 1.5 years ago,
> but you see, it was unfortunately named ``Meta-CVS'', and so people
> somehow don't see it as a proper sequel.  If the sequel to The Matrix
> was called ``Riemann Sphere'', perhaps few would get it either.
> 
> Meta-CVS does directory structure versioning, and other things. but
> it's not CVS II!  Why? Because it's not *called* CVS II, and besides,
> it's not backward compatible.  Never mind that it uses CVS for
> everything: branching, merging, diffing, annotating, viewing logs etc.
> and that it's nearly command-for-command compatible. What it stores
> in the CVS repository can't be grokked by CVS I clients. (Just like
> ANSI C programs can't be grokked by K&R compilers; are those programs
> not written in C?)
> 
> Okay, so if this is not legitimate, let's hear a concrete plan about
> how CVS can be extended to make a ``CVS II'' which is completely
> backward compatible with CVS I clients, and works as well as Meta-CVS.
> Better yet, let's see some code. It's not enough to propose alternative
> ideas when the existing idea is already coded. The CVS mailing list has
> seen more than a *decade* of idle discussions about this subject already.

In some respects I think this last paragraph is unfair.  I've seen
lots of different ideas over the last couple of years that get 
squashed loudly whenever they are brought up.  Why would people want
to contribute when there is no interest in changing cvs.  Or when
people do show interest they get yelled at for not doing it the
'pure cvs' way.   

donald
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs




reply via email to

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