[Top][All Lists]

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

Re: giving up CVS

From: Greg A. Woods
Subject: Re: giving up CVS
Date: Fri, 14 Sep 2001 23:50:55 -0400 (EDT)

[ On Friday, September 14, 2001 at 18:39:58 (-0700), Paul Sander wrote: ]
> Subject: Re: giving up CVS
> It's because repeated calls for change have gone ignored.  Ignoring
> complaints does not make them go away.

Well, I've certainly not ignored them.  Whenever I've come across them
I've pointed out that CVS is not the right tool to use for tracking
changes made to non-text files.  That hasn't made them all go away, but
I'm trying as hard as I can!  ;-)

> CVS *was* built on top of tools which exclusively *used* text-based
> algorithms to manage content and to detect and merge changes.  Since RCS
> 5.7 came out circa 1993 and the subsequent CVS support of the -kb
> keyword expansion capability was added, CVS has been able to "manage
> content" that was not ASCII.

Paul you seem to hold '-kb' in such reverence, but yet you seem to so
conveniently forget that the '-kb' flag in RCS has no influence
whatsoever on the diff/merge algorithms used by RCS (or by CVS, for that
matter).  Perhaps you don't want to see just exactly how all the magic
works (or doesn't work, as the case may be).

The '-kb' flag, in concert with the '-a' option to 'diff' and 'diff3',
and their corresponding ability to deal with arbitrary long lines, only
affects the way line separators and RCS keywords are handled (and the
former only courtesy any special hooks in the stdio library on the
platform of choice.  There is no magic here.

> CVS is not appropriate for tracking non-text files insofar as the people
> who have commit permission to the definitive sources continue to ignore
> these calls for change.

Perhaps you don't see a need to maintain a version of CVS that does what
it was designed to do.

Perhaps you don't understand the purpose, indeed the very "raison
d'ĂȘtre", of the GNU Public License that ``protects'' the CVS code.

>  CVS is perfectly capable of supporting even
> unmergable file types with only minor changes to its logic, specifically
> by adding an extensible mechanism to select the correct merge tool for the
> data type at hand.

So you seem to claim.  So far though you've only proposed the most
superficial of functional specifications, and certainly there's been no
appearance of running code to cloud the issue....

> This is only true as long as CVS treats everything as text files.  There
> is nothing holding us back from modifying CVS to accomodate non-text
> files in a meaningful way and still retain the concurrent development
> paradigm intact.

Go for it.  I look forward to seeing your "Binary CVS" edition in the
very near future!

Hopefully with it you can steal away all the people who are currently
abusing the original CVS by trying to use it to manage change in
projects containing binary files.  Best wishes and good riddance!  ;-)

                                                        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]