[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: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-26 00:00:55 CEST

Ben Collins-Sussman wrote:

> Someone in IRC had a file with 'svn:eol-style=native' attached, and
> then he manually set 'svn:mime-type=FOO', where FOO was in fact a
> textual type, but some type not (yet) in svn's knowledge base. So the
> svn client assumed it was a binary file.
> 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?
> My response was: "Well, maybe this behavior is a safeguard. For
> people who recklessly set 'eol-style' on every file, it prevents
> corruption of binary files."

Nah, it's a bug. Our policy always was that we shouldn't modify file
contents by default, but if the user requests it via one of the relevant
properties (svn:eol-style, svn:keywords), then it's the her
responsibility to do it correctly. That's why we allow keyword expansion
in files that are binary according to their svn:mime-type.

> Regardless, there's a tension here. Possible options include:
> 1. make eol-style always work, no matter what. removes the safeguard,
> possibly risks data corruption among newbies.

This is what we should do.

> 2. continue to expand svn's internal list of "texty" mime-types.

Sooner or later we'll have to throw that list away in favour of a
platform-specific mechanism (mime.magic on Linux, registry on Windows,
etc.) moderated by a server-side autoprops configuration.

> The problem with #2 is that it just doesn't scale well. cmpilato
> predicts this problem is only going to get worse over time, and we
> won't be able to keep up. The fact that we've conflated
> "svn:mime-type" with "is textual and safe for contextual diffing" is
> arguably a mistake, despite the convenience

No, it's not a mistake, the mechanism is simply not generic enough yet.
Once we understand the charset component of the content type, and have a
mapping between MIME types and diff methods, everything should work just

> An idea floating around the Chicago office is to add a new property:
> 'svn:text'. If this property exists, then it *authoritatively* means
> the property is text-y and safe for contextual diffing/merging. If it
> doesn't exist, then svn resorts to looking at 'svn:mime-type' to
> hazard a guess.
> Is this a reasonable solution? If people like it, I can file a new
> feature request.

In one word: yuck.

If we assume that using the svn:mime-type to determine textiness can't
be made flexible enough, then adding a property to represent that single
bit of information gets us nowhere. It would be much better for the
property to define merge behaviour, starting with the simplest "none"
and "use-diff3" and at least leaving the door open for assigning
different merge engines based on content.

Although I still think the same information can be determined from the
MIME type, if its set correctly. It would be a bit weird of the
mime-type property were suddenly used only by mod_dav_svn, and you'd
have to set /another/ property with essentially the same information
content. The problem with svn:mime-type isn't that it doesn't contain
enough information, but that it's a PITA to set correctly. Even
auto-props don't help much because they're a strictly client-side
config, whereas the behaviour should be specific to (a subtree in) the

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 26 00:01:02 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.