RE: cvswrappers - any better suggestions ?

[Paul Sander]

Greg's statement below is flatly untrue.  We've discussed this very topic
at length in this forum many times in the past.  His argument is based on
the fact that the RCS "merge" tool cannot support merges of arbitrary
file formats.  It doesn't even support merges of arbitrary ASCII formats.
And yet, the CVS community attempts to use it in that capacity all the
time.

There are application-specific merge tools for numerous file formats,
some of which are useful for software development.  Others don't exist
but can be written without great effort.  When all else fails, there's
always the trivial binary or trinary file selection algorithms.  And don't
forget that there are the many existing text-based merge tools that people
prefer using, such as the one supplied with Emacs.

Inserting a registrar into CVS to allow shops and users to specify the
particular tool required to perform a merge is not a fundamental change to
the CVS design, but it is a small generalization.  And it's one that will
greatly benefit the CVS community in general.  Such a mechanism does NOT
affect in the slightest way ANY aspect of the concurrent development model
that CVS implements.  (It is basically just parameterizing the hard-coded
path to the RCS-supplied merge tool, or its equivalent in the librified RCS.)

--- Forwarded mail from address@hidden

>[ On Sunday, April 1, 2001 at 14:00:20 (-0700), David Glick wrote: ]
>> Subject: RE: cvswrappers - any better suggestions ?
>>
>> BTW, I *do* get it; I just don't agree with you.  I've spent most of
>> 20+ years listening to people just like you explain why something
>> shouldn't/couldn't be done, and then finding ways to make it happen
>> anyway.  Clearly, other people feel the same way, because CVS does
>> support binary files after a fashion.  I just want them supported
>> better.

>Clearly you do not get it at all.  CVS literally cannot support binary
>files in any better fashion without becoming something that will no
>longer be a "Concurrent Versions System".  It was designed specifically
>to force concurrent editing and that design goal permeates the way it
>works through and through (despite the valiant attempts by others to
>bend it to suit their twisted ideas).  You cannot throw out the bath
>water without throwing out the baby in this case -- they are one in the
>same.

--- End of forwarded message from address@hidden