[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: |
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
- Re: How well does CVS handle other types of data?, (continued)
- Re: How well does CVS handle other types of data?, Lan Barnes, 2001/07/12
- Re: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/12
- RE: How well does CVS handle other types of data?, Sven Dowideit, 2001/07/12
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/12
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/13
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/13
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/14
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/14
- Re: How well does CVS handle other types of data?,
Paul Sander <=
- Re: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/12
- Re: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
RE: How well does CVS handle other types of data?, Thornley, David, 2001/07/12
RE: How well does CVS handle other types of data?, Noel L Yap, 2001/07/12