On Fri, Nov 13, 2009 at 08:30:53AM +0100, B. Smith-Mannschott wrote:
> Please give me a property with which I can explicitly communicate my
> intent wrt merging. Please don't munge this information into an
> existing property by trying to interpret extra meaning from it.
> As an example of how I've come to feel this way, let's consider XML:
> We've got lots of XML files in our repository. Some of them make sense
> to merge (Maven's pom.xml) and some do not (UML models stored in XMI
I think this is a very good point.
So "textiness" does not imply "mergeable". A file might contain text
in some character encoding, but a merge tool may not be able to handle
it properly because of the application-level semantics the text represents.
It would just garble the file.
Mike, I think this is quite important. It means that even just looking
for "text/*" is totally wrong. Extending this flawed mechanism by making
Subversion look for "; charset=" is not gonna help. The subject of this
thread should not be "Classifying files as binary or text" but "How to
determine whether a file is suitable for being merged?".
So I'd favour Branko's proposal, a property which communicates to Subversion
whether file content is suitable to be passed to a diff or merge tool,
regardless of the mime-type. Branko (or anyone else), could you work on
extending this proposal by defining behaviour such as what should happen
when a new file is added (will this property always have to be set manually
or will it be set automatically in some cases?), what should happen if the
property is set on merge-left but not on merge-right or on the merge target,
and whatever other corner-cases we can think of?
A new file in notes/ would be nice :)
The svn:mime-type property still has its place, e.g. it is useful
whenever a specific mime-type should be sent to a web browser browsing
a Subversion repository. But I agree with deprecating its use to detect
Received on 2009-11-13 12:41:51 CET