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: Thu, 12 Jul 2001 18:16:29 -0700

>--- Forwarded mail from address@hidden

>[ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> You've made your position abundantly clear, and yet I still do not
>> understand your ideas -- nor your vehemence. So what is left is that we
>> disagree.

>It's really very very simple.  Perhaps the problem is that these issues
>are actually simpler than many people want them to be.  Various people
>continue to try to suggest the impossible, and then refuse to accept the
>plain simple facts.  You appear to be among them.  You cannot have your
>cake and have eaten it too!  You can't have good support for change
>management of non-mergable files in a version control system who's very
>design and core functionality hinges on the ability to easily and
>automatically do three-way merges betweeen revisions.  The more
>unmergable files you add to a normal (i.e. a non-vendor-branched) CVS
>repository, the more likely you'll run into increasingly difficult
>problems.  The fewer unmergable files you have the easier it is to treat
>them as special cases.

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.

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?

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.

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




reply via email to

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