Julian,
Since there seems to be quite a bit of confusion over what you have
proposed, can you repost it. Perhaps you could show the diffs from
the current FAQ as the first post of this thread does for the
svn:merge-mode proposal.
mike
2009/11/18 Julian Foad <julianfoad_at_btopenworld.com>:
> 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=2419637
Received on 2009-11-18 19:16:42 CET