Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Merge mode (Was Classifying files as binary or text)

subversion
Discussion topic

Back to topic list

Merge mode (Was Classifying files as binary or text)

Author mikesamuel
Full name Mike Samuel
Date 2009-11-17 12:56:44 PST
Message 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.ti​gris.org/faq.html#bi​nary-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/rfc428​8.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.

« Previous message in topic | 1 of 30 | Next message in topic »

Messages

Show all messages in topic

Merge mode (Was Classifying files as binary or text) mikesamuel Mike Samuel 2009-11-17 12:56:44 PST
     Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-17 13:09:23 PST
         Re: Merge mode (Was Classifying files as binary or text) mikesamuel Mike Samuel 2009-11-17 13:33:29 PST
             Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-17 15:19:01 PST
                 Re: Merge mode (Was Classifying files as binary or text) mf Martin Furter 2009-11-17 16:19:02 PST
                     Re: Merge mode (Was Classifying files as binary or text) mikesamuel Mike Samuel 2009-11-17 17:57:42 PST
                         Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-17 23:38:46 PST
     Re: Merge mode (Was Classifying files as binary or text) markphip Mark Phippard 2009-11-17 13:35:01 PST
     Re: Merge mode (Was Classifying files as binary or text) bpsm B. Smith-Mannschott 2009-11-17 13:46:19 PST
         Re: Merge mode (Was Classifying files as binary or text) mikesamuel Mike Samuel 2009-11-17 13:48:06 PST
     Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-17 19:05:36 PST
         Re: Merge mode (Was Classifying files as binary or text) mikesamuel Mike Samuel 2009-11-17 20:23:40 PST
             Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-18 03:10:00 PST
         Re: Merge mode (Was Classifying files as binary or text) glasser David Glasser 2009-11-17 23:26:07 PST
             Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-17 23:44:23 PST
             Re: Merge mode (Was Classifying files as binary or text) bpsm B. Smith-Mannschott 2009-11-18 00:47:44 PST
                 Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-18 02:54:06 PST
                     Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-19 00:34:59 PST
         Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-18 02:55:21 PST
             Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-18 03:16:17 PST
                 Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-18 03:31:48 PST
                     Re: Merge mode (Was Classifying files as binary or text) brane Branko Cibej 2009-11-18 03:43:47 PST
             Re: Merge mode (Was Classifying files as binary or text) bpsm B. Smith-Mannschott 2009-11-18 03:31:31 PST
                 Re: Merge mode (Was Classifying files as binary or text) markphip Mark Phippard 2009-11-18 05:22:15 PST
                     Re: Merge mode (Was Classifying files as binary or text) julianfoad Julian Foad 2009-11-18 07:27:36 PST
Page: of 2 « Previous | Next »
Messages per page: