I thought I'd start a new thread about issue 1002 with a writeup of
Branko's merge mode property. The proposal is first, followed by the
same background as before and slightly updated goals.
Proposal:
========
(1) Add documentation on the svn:merge-mode property that lists the
allowed values as ("simple" and "none")
(2) Add example autoprops rules to the documentation that sets
svn:merge-mode to "simple" for the following file types
application/ecmascript
application/json
application/xml
image/svg+xml
(3) Change the text quoted from the SVN manual under Background to
read as below.
(4) Update the implementation to agree.
Subversion treats the following files as [[mergable]]:
* Files with no svn:mime-type [[and no svn:merge-mode]]
* Files with a svn:mime-type starting "text/"
* Files with a svn:mime-type equal to "image/x-xbitmap"
* Files with a svn:mime-type equal to "image/x-xpixmap"
* [[Files with a svn:merge-mode that is equal to "simple"]]
All other files are treated as [[unmergeable]], meaning that
Subversion will:
* Not attempt to automatically merge received changes with
local changes during svn update or svn merge
* Not show the differences as part of svn diff
* Not show line-by-line attribution for svn blame
In all other respects, Subversion treats [[mergable]] files the
same as [[unmergeable]] files, e.g. if you set
the svn:keywords or svn:eol-style properties, Subversion will
perform keyword substitution
or newline conversion on [[unmergeable]] files.
Goal:
====
To update the scheme by which svn {update,diff,merge,blame} to allow
merging of files
with svn:mime-type outside the hard-coded list currently used.
This determination should be independent of the platform svn
is running on, so independent of the set of supported character sets.
This scheme should not complicate future extensions to the merge
system which might wish to use a different merge policy, e.g. for XML
than for source code files.
This scheme should work with autoprops, and other mechanisms repository
administrators use to manage files. Specifically, some kinds of XML can
be meaningfully meged, and others cannot.
This scheme should work within existing limitations, such as the inability
to merge UTF-16 and UTF-32.
Background:
==========
The current behavior is described at
http://subversion.tigris.org/faq.html#binary-files
Subversion treats the following files as text:
* Files with no svn:mime-type
* Files with a svn:mime-type starting "text/"
* Files with a svn:mime-type equal to "image/x-xbitmap"
* Files with a svn:mime-type equal to "image/x-xpixmap"
All other files are treated as binary, meaning that Subversion will:
* Not attempt to automatically merge received changes with
local changes during svn update or svn merge
* Not show the differences as part of svn diff
* Not show line-by-line attribution for svn blame
In all other respects, Subversion treats binary files the same as
text files, e.g. if you set
the svn:keywords or svn:eol-style properties, Subversion will
perform keyword substitution
or newline conversion on binary files.
Common source code mime-types are misclassified, and that problem is
likely to grow because of current IANA policy.
Mime-types are handed out by the IANA, which only assigns text/*
mime-types for file-types that are meant to be human readable. Source
code is explicitly not considered human readable. This is why many
source code and data mime-types are in the application/* group or
other non text/* groups: application/json, application/ecmascript,
application/xml, image/svg+xml.
RFC 4288 ( ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt ) says this
Expected uses for the "application" media type
include but are not limited to file transfer, spreadsheets,
presentations, scheduling data, and languages for "active"
(computational) material.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419155
Received on 2009-11-17 21:56:52 CET