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

Re: property co-existence problems.

From: Fred L. Drake, Jr. <fdrake_at_acm.org>
Date: 2004-10-26 00:24:18 CEST

Ben Collins-Sussman wrote:
> He was rightfully annoyed that the eol-style property was being
> ignored. Sure, he could just remove the 'mime-type' property, but it's
> might be considered a bug that the behavior 'eol-style' is affected by
> other properties at all, right?

I'll step in and explain what I saw in more detail, since it's sensitive to
the order in which properties are set (which I found *very* surprising).

If I set svn:mime-type=application/xml-dtd and then svn:eol-style=native, the
first propset succeeded and the second complained that the file was binary.

If I reverse the order of the propsets, both succeeded.

Attempting to set both using auto-props failed; it appeared that the
svn:mime-type was being set before svn:eol-style, though the two properties
were listed with svn:eol-style first in the corresponding auto-props entry
(only one entry applied).

I didn't actually test what happened on a checkout on a system with a
different line-end convention, and make no claims about the actual behavior
once the svn:eol-style property is set. Only that attempting to set both of
these properties behaved in strange ways.

> 1. make eol-style always work, no matter what. removes the safeguard,
> possibly risks data corruption among newbies.

On Monday 25 October 2004 05:13 pm, Julian Foad wrote:
> Sounds pretty good to me. Unfortunately it would be unsafe to do this
> before version 2, as some people might have got themselves binary files
> with svn:eol-style set. We could phase in the change by first (now)
> starting to warn when this combination of properties is encountered.

Agreed. I could live with the warning, though I can imagine others may become
quite annoyed at such things.

> Actually, it's more that the idea of "is textual and safe for contextual
> diffing" is flawed. That assumes that there is just one kind of
> diff/merge, and it works on a content type that we casually call "text".

I agree on this as well. I can generally live with this, though it's less
than ideal.

[re: svn:text]
> I think that's the wrong way to go. The right way to go is towards having
> a mapping from mime-type to diff-method, where "none" is just the default
> diff method for mime types for which no suitable diff method is installed.

This makes the most sense. I can see the "default" diff method being to use
the current textual diff for anything with svn:eol-style set or a text/* mime
type. (Which might be what you meant here; I'm not sure.)


Fred L. Drake, Jr.  <fdrake at acm.org>
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 26 02:48:21 2004

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.