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
fine.
> 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
repository.
-- 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