RE: merge mode for XML

[Paul Sander]

>--- Forwarded mail from address@hidden

>> > > No.  Not on extension, but based on *regular
>> expressions*, or at least
>> > > shell-style   pattern  matching   expressions.
>> Extensions   are  too
>> > > simplistic.  (c.f. CVSROOT/cvswrappers,  CVSROOT/cvsignore)
>> >
>> > Extensions would work fine, pattern matching is overkill.
>>
>> Neither is suitable or sufficient.
>>
>> The actual type must be explicitly recorded in every delta,
>> or at least
>> the initial delta and every delta following a "dead" delta.

>on earth, extension matching would be fine.  Unless you have rogue
>developers that "try" and break the system by changing file formation while
>keeping extensions the same (save it as a jpg, but it is really a gif
>format) you should not have a problem.  If you do have rogue developers, or
>even developers that can't follow simple instructions such as "hey, if it is
>not a jpeg then don't save it as a jpeg!" then you have much larger
>problems.
>ie. maybe the inmates of San Quinton do not make the idea
>development team.

I think Greg's point here is that there are times when a file is removed
and later replaced with a new one that contains a different type of data.
Case in point:  ASCII text file names foo.doc is replaced by a Microsoft
Word document containing the same content and is stored with the same
name.  It could be argued that this practice is unsound, but it does happen.

There's no good solution to this problem using the current CVS design,
but Greg suggests a workaround that works well enough in some common cases.
There are other times when the data type is the same but the content is
completely unrelated, in which case the diff/merge should be avoided
altogether.  But CVS punts this scenario.

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