On Wed, 2009-11-18 at 10:50 -0500, Mark Phippard wrote:
> 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.
You seem to have got the idea that I was proposing just looking at
filenames. I was not. I said there should be a mechanism for specifying
the merge-mode (and also, separately, the diff-mode and the blame-mode)
as a function of the tuple
(svn:mime-type, filename, content, svn:merge-mode)
Now I'm thinking let's generalize that further and have it a function of
(properties, filename, content)
and supply a good default configuration built-in, and supply an example
plug-in configuration or two.
> 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.
Just because we can't merge all XML "properly" doesn't mean we can't
supply a sane default (yes or no) as a starting point for the users to
customize.
> This is one of the
> main mime-type that has been a problem. So how does your solution
> even begin to address this?
By allowing the default to come from svn:mime-type (or a function of
(svn:mime-type, filename, content)) and allowing the user to override it
with a special svn:merge-mode property. And of course svn:diff-mode and
svn:blame-mode.
> 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.
Great.
> But we still need to something like
> svn:merge-mode to cover the other types where it is not a binary answer
Yes, I agree. (Modulo my assertion that a yes/no answer is 99% useful
for most file types: for most people it is not important to be able to
tell Subversion to try to built-in-merge some XML files but not others,
I assert.)
> and that is all the proposal was ever about.
No, I don't think it was only about the cases where you can't get a
definite answer from the svn:mime-type, I think it was aimed at covering
up the gaping holes in our recognized MIME type list.
The cases where you can't get a definite answer are just an additional
requirement that mean some people want such an additional mechanism
anyway.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419597
Received on 2009-11-18 17:39:42 CET