[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: Branko Cibej <brane_at_xbc.nu>
Date: Fri, 13 Nov 2009 02:14:01 +0100

Mike Samuel wrote:
> 2009/11/12 Mark Phippard <markphip_at_gmail.com>:
>
>> On Thu, Nov 12, 2009 at 6:20 PM, Mike Samuel <mikesamuel_at_gmail.com> wrote:
>>
>>> Conclusions from the svn:charset thread that Mark pointed out:
>>> (1) This proposal should not gate on svn:charset since it isn't yet
>>> recognized as official
>>> (2) We should avoid the term encoding in documentation of this feature.
>>> (3) There may be some bad interactions between ";charset=" in
>>> svn:mime-type and auto-props, but this proposal does not raise new
>>> issues, and those issues are a result of an error (possibly since
>>> fixed?) in auto-props.
>>>
>>>
>>> From the svn:charset thread:
>>>
>>> Much of the early debate deals with svn:charset being non-standard and
>>> non-approved. I tend to agree with Stefan, that this proposal
>>> shouldn't gate on svn:charset being approved so I suggest tabling
>>> variant 1.
>>>
>> Correct me if I am wrong, but the only real goal we have right now is
>> to improve SVN's ability to tell itself "this is text" and I can do
>> textual merging?
>>
>
> That is correct.
>
>
>
>> So why not just add an svn:text property that has a
>> value of '*'. The presence of the property means "treat this as
>> text".
>>
>
> To make sure I understand your counter-proposal, would a file be
> treated as text if at least one of (svn:mime-type starts with "text/"
> or matches the existing whitelist) OR (svn:text exists and is "*")?
>
> Or are you advocating dropping the first clause which is there for
> backwards-compatibility?
>

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.

-- Brane

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