[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Merge mode (Was Classifying files as binary or text)

From: Mike Samuel <mikesamuel_at_gmail.com>
Date: Tue, 17 Nov 2009 12:56:44 -0800

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.