info-cvs
[Top][All Lists]
Advanced

[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,
>again?

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
helpful.

>> 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
>be.

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]