Hi Julian,
Do you mean: give a warning and not add image1.gif; then continue to
add text2 and try (but fail) to add image2.gif? That might be
reasonable.
The ideal is to add all the files requested, without further ado --
binaries as binaries, and text files with eol-style=native.
I think you meant: add image1.gif and set its EOL style to "native"
No, I totally agree we don't want eol-style=native for binary files, and
wasn't suggesting that. Sorry if that wasn't clear. (That turned out
to the stopper with my kludge attempts yesterday. Philip, thanks for
the pointers on further hacking, but it sounds like pursuing the
mime-type approach is better anyway ...)
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.
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.
It would be convenient if Subversion provided a way to do what you
want directly,
Yes :).
but I think a reasonable solution for your purpose is to run (after
the "svn add") a simple program that sets svn:eol-style on all files
that do not have svn:mime-type. Would that be acceptable?
That does sound a whole lot better than trying to maintain a complete
file extension list. Thanks very much for the idea; I think I'll do it.
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.
Thanks for the replies,
karl
P.S. Another stumbling block is not being able to specify the
configuration once on the server, instead forcing each developer to set
the same properties. Even CVS has repository configuration :). I
recall that being discussed in the same thread last April as well, so I
won't belabor the point further ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 17 17:51:05 2005