>--- Forwarded mail from [EMAIL PROTECTED]
>[EMAIL PROTECTED] on 02/17/2000 10:47:34 AM
>>>--- Forwarded mail from [EMAIL PROTECTED]
>>>I'll agree with you though if you say that there may not be any sensible
>>>method to automatically merge certain file-formats and keep the syntactic
>>>and semantic format of the file "correct"...
>>
>>That is exactly what I meant. I had assumed that the definition of "working
>>merge tool" included the notion that what it produced would have the
>>following properties:
>>
>>1. The output is meaningful, i.e. it is understandable as valid source code
>> by the tool(s) that interpret its content and that of the contributors.
>>2. The output contains elements from the contributors. Such elements may be
>> intermixed, possibly under the direction of the user.
>>3. The output has the proper semantics as defined by the user.
>There will never be a generic merge tool because of the above requirements (I
>mean, how will a generic merge tool know how a particular tool interprets
>source?) However, in an ideal world (which I know we don't live in), tool
>vendors will ship diff/merge tools with their tools or open source diff/merge
>can exist. It'd be great if such tools can be written for VB for example.
It would be good if CVS would permit the integration of additional diff
and merge tools, too. At least that way it could be taught how to merge
files that give diff3 heartburn.
>OTOH, there are other tools which I think can never have diff/merge algorithms
>(image editors come to mind). For these tools, I think 'false' would be a good
>merge tool.
Unfortunately, CVS doesn't have a good recovery path for a merge failure.
I'm not sure that one is possible or desirable.
>--- End of forwarded message from [EMAIL PROTECTED]
