[Top][All Lists]

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

Re: cvs diff, proposal for change

From: Paul Sander
Subject: Re: cvs diff, proposal for change
Date: Thu, 4 Sep 2003 23:33:24 -0700

>--- Forwarded mail from address@hidden

>[ On Wednesday, September 3, 2003 at 13:07:52 (-0400), Terrence Enger wrote: ]
>> Subject: cvs diff, proposal for change
>> In general, the concensus of those in the know has been
>> negative: cvs diff is so far from working with arbitrary files
>> that it is not even worth thinking about changing it.
>> Nevertheless, I beg your indulgence as I put forward this
>> preliminary proposal for changes.

>"cvs diff" itself is just the very tip of the iceberg.

>The same text-based delta algorithms go right to the core of how RCS
>files work.

While it is true that the same algorithms are used for two purposes
(computing RCS deltas and presenting differences to users), what's
really happening is that the diff program just happens to be invoked
in two distinct sections of the CVS application.  In the section that
maintains the RCS file format, the diff program absolutely must be used.
But in the other part, the part that displays differences to the user,
any tool will do, and in fact the diff program is sometimes the wrong one
to use.

In other words, I don't believe anyone who says "replace diff" really
means "do a global search for the string d-i-f-f and replace all occurances
with something else."  Instead, I think they really mean to leave the part
that maintains the RCS file format alone, and replace the diff program
only where it produces user-visible output that is not interpreted by
the CVS application itself.

>If you want to store abitrary (and especially unstructured) binary data
>in a version control system then CVS (and RCS) never was, and never will
>be, an appropriate choice for your purposes.

There are plenty of unmergeable, text-based file formats.  I think you'll
find that using RCS to archive such files is no less efficient than using
e.g. tar, and you still get the benefits of RCS labelling and branching
and revision states.  'Course, unmergeable files don't lend themselves to
a concurrent development paradigm by definition, so any arguments that
relate to that are moot because there's no expectation for it to work.

On the other hand, there also exist mergeable binary types, and CVS should
support those.  Naturally they don't lend themselves to any text-based diff,
and other tools that produce meaningful representations of differences
should be used instead.

>--- End of forwarded message from address@hidden

reply via email to

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