[Top][All Lists]

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

Re: How well does CVS handle other types of data?

From: Paul Sander
Subject: Re: How well does CVS handle other types of data?
Date: Fri, 13 Jul 2001 00:31:37 -0700

>--- Forwarded mail from Greg Woods

>[ On Thursday, July 12, 2001 at 18:16:29 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>> Every type of file is mergeable; trivially, the merge can be complete
>> replacement.  In other words, a viable merge algorithm is a 3-way switch,
>> without regard for content.

>Hah!  Yeah, but how do you measure the intent of the changes you're
>choosing between?   :-)

The user makes the selection during the merge.  This can be either via
interaction, or via a hint that's given to the client.

>> Many non-text data types have viable content merge tools.
>> Many text-based formats are not mergeable using general-purpose tools.
>> Why can't CVS support these kinds of data in a general way, rather than
>> forcing the worn-out RCS merge tool upon the world?  Why is it such a bad
>> idea to add to CVS a way of identifying data types and invoke the proper
>> merge tool for each type?

>Why don't you read the archives for the fairly recent thread that
>covered this issue in detail?  Oh, I forgot!  You were a primary
>participant in those discussions?  So, why do you ask such a question,

I remember the many discussions.  They go something like this:

Me:    CVS should support non-text source files.
Greg:  No, it should not.
Me:    But many users need to.
Greg:  They should use something else.
Me:    But CVS can support them with a little change.
Greg:  CVS is perfect as it is.
Me:    CVS should change to accomodate its users.
Greg:  Making the change would violate the "concurrent" part of CVS,
       it was not designed to support such data, it requires a change to
       the format of the repository, and I don't want it.
Me:    None of these technical issues prevent the addition of support, and
       here's why...
Greg:  CVS as implemented today doesn't work that way, so you can't do it.
       And you're stupid, too.

This is really quite tiring.  And in the end, Greg's arguments are not

>> The basic design of CVS is not fundamentally altered by this, and the
>> repository remains binary-compatible with what exists today.  As far as
>> I can tell, there is no disadvantage to adding this, and great advantage.

>No, the basic design would not be altered, but the specific
>implementation details on which various compatability issues hinge would

Oh, so now the CVS design is compatible.  We're finally making progress.
The implementation can be changed.

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

reply via email to

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