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

Re: Classifying files as binary or text

From: B. Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Fri, 13 Nov 2009 08:30:53 +0100

On Fri, Nov 13, 2009 at 02:14, Branko Cibej <brane_at_xbc.nu> wrote:
[snip]
>
> I think we all agree that using the MIME-type to decide whether we can
> use contextual text-base merge for a file has turned out to be trickier
> than we originally expected. It makes sense to find a better solution to
> the problem.
>
> I would suggest just slightly future-proofing Mark's proposal, and
> certainly staying backward-compatible. The rules should go like this:
>
>    * If a file has no content-related property (i.e, no svn:mime-type),
>      treat it as text.
>    * If there's only an svn:mime-type property, keep its current semantics.
>    * Introduce a new property that overrides svn:mime-type, but don't
>      call it svn:text (which implies it's a boolean), but, e.g., just
>      svn:type or svn:merge-mode or some such.
>
> The value of this property is a keyword. Initialliy, the allowed values
> would be "text" and "binary", but I can imagine adding "xml" in the
> future if someone wants to add XML-aware merging (I've come across such
> requests everal times, have used a similar feature in ClearCase to good
> effect). svn:mime-type needn't go away or be deprecated; It's useful in
> other contexts.

As a Subversion user, I'd like to second this proposal!

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
format).

Currently, I use the hack of declaring the human-editable XML's to be
text/xml, and the others as application/xml. I'd much rather use the
more canonical application/xml, considering that we serve our
repository over https. It would be idiotic to have to specify
'charset' in this case because XML *already carries it's charset
internally*. I don't like to repeat myself while programming; that
just breeds contradictions.

// Ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417446
Received on 2009-11-13 08:31:14 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.