Karl Berry wrote:
> No, I totally agree we don't want eol-style=native for binary files,
[...]
> client obey svn:eol-style regardless of MIME type, because that
> would be useful in the case of MIME types that Subversion doesn't
> recognise but that are nevertheless for text files.
>
> For mime types that subversion does not recognize, I can see the point.
>
> For mime types that subversion knows are binary, like
> application/octet-stream, it seems it could only cause trouble to ever
> look at eol-style. So I hope you don't do that.
Well, I agree that it seems dangerous to change the line endings in a binary
file, but it would also be wrong for Subversion to silently ignore a setting
that the user made. Subversion doesn't actually have a very good idea of what
is binary and what is text. You say "binary, like application/octet-stream"
but as far as I know that is the only MIME type that Subversion knows is
binary. The user knows better (sometimes). Perhaps the best thing in this
situation would be for it to give an error or a warning.
> Making eol-style settable based on mime-type, as well as file extension,
> seems like it gives users the flexibility to handle both known and
> unknown mime types in whatever way is desired.
Well, yes and no.
Note that Subversion doesn't know the MIME type of a file during "import" or
"add". The only thing it does is looks at the beginning of the file to see if
it looks "binary", and if so it sets svn:mime-type to
"application/octet-stream". Just before or after this (I hope it's well
defined), the auto-props operate, and can set svn:mime-type according to file
name. This combination is powerful enough to set the MIME type correctly for
many situations, but not as good as being able to run an external MIME type
detecting program (e.g. the Unix "file" command).
There is little point enhancing the auto-props mechanism to allow testing
svn:mime-type for various patterns, because if it wasn't set by an auto-prop
depending on file name, then it is either "application/octet-stream" or
nothing. The only new bit of functionality needed is a way to detect this last
bit.
After the import or add, you probably want to go through the files and give
them better MIME types. If you do this, then you might as well set
svn:eol-style appropriately as well. However, I can still see that you might
not want to do this because you are not interested in the MIME types, and
Subversion's binary/text guess works accurately enough for you, and you just
want all the files that were guessed as text to have svn:eol-style set.
What new functionality would best accomplish this?
How about the ability to specify:
+ What properties to set for files detected as binary;
+ What properties to set for files detected as text.
You see, I don't want another highly-specialised option such as one which just
sets svn:eol-style when it doesn't set svn:mime-type. Someone would just come
along next month saying that that's all very well but they want to set
"my-merge-mode=line-based" on all text files, as well as svn:eol-style.
On the other hand, what I suggested is only slightly more flexible. I tend to
conclude that it is not the job of "svn add" or "svn import" to set all the
properties the way you want them. At least, if it is, then it needs to be done
with a hook so that arbitrary code can be invoked.
The auto-props mechanism is a very limited feature and it feels wrong to extend
it in ad-hoc ways.
[...]
> We're all volunteers here, so I can't really complain that anything is
> unacceptable :). However, it does seem to me that every project with
> cross-platform developers would like to have the behavior that binary
> files are binary, and text files have eol-style=native. Making it
> easier for this to happen, one way or another, would remove one
> stumbling block to subversion adoption.
Yes, I pretty much agree. I just don't like extending auto-props to accomplish
that one particular setting, and would prefer a much more general approach such
as us supplying a script that can be customised to do exactly what each team wants.
> P.S. Another stumbling block is not being able to specify the
> configuration once on the server, [...]
Yes. That's being discussed again at the moment. It's certainly wanted, but
nobody yet seems to have taken on the non-trivial task of evaluating the needs
and possibilities and coming up with a good design for it. Several people have
said things like "Why don't you just have a file on the server that is
downloaded" or "You could do it with inheritable properties", but it needs a
deeper proposal than that.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 17 20:56:38 2005