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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs