On Wed, Nov 18, 2009 at 10:27 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Mark Phippard wrote:
>> The reply message I am top-posting to sums up my feelings exactly. I
>> think Julian's proposal would be a step-backwards and really not even
>> help with the problem at hand.
>
> Mark, I'm sorry you got that impression, and you don't seem to be the
> only one. I must be poor at expressing myself, combined with that I am
> only struggling towards the best solution and have not got all the
> answers (yet).
I just do not think file extensions really helps much. You gave the
Perl example in this email where it would, but in your proposal you
talked about application/xml and that is an example where it does not
really help. I actually think the original proposal of adding charset
is probably a better approach for what you seem to want to accomplish.
> I understand only a small part of the reasons why you feel that. If I
> may be so cheeky as to paraphrase, I felt it sounded a bit of a "just
> give the user another knob to twiddle and he'll shut up" sort of
> proposal. Not totally; that's unfair, as it has some merits; but there
> was just too much of that feel in it for me to stay quiet.
Well, when it comes down to it, I just think the svn:merge-mode
proposal does a better job of providing a solution than yours will.
>> Despite our penchant for self-flaggelation, it seems like we are
>> forgetting that our current system actually works pretty well for most
>> cases.
>
> Exactly... but the proposal had a tase of abandoning it, with a mere
> concession to keeping it for backward compatibility rather than
> recognizing its value and extending the principle (the principle of
> selecting a processing mode based on content type).
I don't know, if anything the proposal seems even better for this.
That is why the proposal calls for a property named svn:merge-mode.
So that it could be possible to inject different modes of processing
in the future.
> It's the "small subset of file types" that's contentious. That may have
> been the case for typical svn users a few years ago but now many
> mainstream textual files have types we consider "binary".
>
> If I use the trunk's new and very useful config option "mime-types-file
> = /etc/mime.types" and then "svn add" a .pl Perl script, it gets an
> svn:mime-type of "application/x-perl". That means that if I continue
> working like that, and we don't update the current svn:mime-type
> recognition, then I'll need to go setting the new prop all my Perl
> files. If I'm a Perl programmer, that basically does mean I need it on
> all my files.
>
> That is a big concern to me: I don't want everyone to get into the habit
> of setting these props all over their data.
This probably is an example of our OCD getting in the way. Why did we
even add this mime.types feature to begin with? Who thought it would
be a brilliant idea to add a "proper" mime-type to every file in the
first place? Basically, we added a feature that was not needed that
cascades to create a problem.
>> B Smith-Mannschott wrote, re why don't we update the built-in recognition:
>> > (1) It's an ongoing maintenance headache.
>
> Sure. So, are we abandoning it in favour of something better? We can't
> claim it's still the main method if we aren't prepared to update it.
>
> Until we replace it, if someone is prepared to update it, should we stop
> them just because it's an ongoing maintenance headache? Of course not.
I think the ongoing maintenance burden would be trying to codify which
mime-types we know we can treat as text. I am not sure it is even
reliable. For example, we could not say we handle application/xml
because there are definite cases where we cannot. This is one of the
main mime-type that has been a problem. So how does your solution
even begin to address this?
In terms of a type like application/x-perl I assume it would be safe
to always treat that as text. Given that we have some precedence for
doing this already I would be +1 on extending that list to cover some
types where we know this is safe. But we still need to something like
svn:merge-mode to cover the other types where it is not a binary
answer and that is all the proposal was ever about.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419559
Received on 2009-11-18 16:50:33 CET