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 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.
> 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).
> There are a limited number of MIME types where there are
> different ways they could be handled, and users already have a built
> in workaround available (remove the svn:mime-type property).
> Apparently users really like serving files directly from their SVN
> servers or their OCD just will not allow them to remove the property.
> In those limited cases, we are simply talking about adding a new
> property to Subversion to let you tell us to treat the file as text.
> There is no need to make this more complicated.
That's fine if the intent is to accompany this with updating the
mime-type recognition and augmenting it with other recognition methods
that we deem worthwhile, so that most users don't need the special
annotation.
> No one is suggesting that users go out and set the svn:merge-mode
> property on all their existing files. It is just a tool we want to
> give users to handle a small subset of file types.
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.
> 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.
> > (2) The merge behavior of existing repositories will change,
> > surprising some, no doubt.
It will change, true. Surprising, yes, to those who don't read the
release notes. A problem? In practice, I really don't see a problem.
> > (3) *The mapping from MIME-type to 'mergeable' is ambiguous.*
> > Consider, again, application/xml. No amount of "updating the built-in
> > list of MIME types" is going to help here.
Yes, absolutely. For those FEW cases where the different XML file
formats don't have their own specialized MIME types and the user REALLY
needs or wants to treat them differently, that's where the "yes, have a
dedicated property as well" part of my pseudo-proposal comes in.
> >>> It is not much harder for Subversion to have a configuarable list of
> >>> which MIME types (or MIME type patterns) should be considered mergeable.
> >>> (The configuration could be extensible: it could say line-wise-mergeable
> >>> or not mergeable or XML-mergeable or ...)
> >>
> >> [...]
> >>
> >>> Solution 0 (merge-mode)
> >>> ==========
> >>>
> >>> So we could add a property to each file which says whether the file is
> >>> to be considered line-wise mergeable by Subversion, and say that this
> >>> property will be the primary source of this information. What are the
> >>> pros and cons of this?
> >>
> >> Big con: Depends on auto-props, a mechanism which is not really good
> >> enough for the task. (Strictly speaking it doesn't, because users can
> >> set the property manually, but in a practical sense it does because in a
> >> production environment it is impractical for users to consistently set
> >> the property manually.)
> >
> > I find this criticism misleading. It leaves the impression that the
> > OP's proposal depends exclusively on the merge-mode property to
> > determine merging behavior. This is not the case. Merge-mode is only
> > needed when the existing heuristics -- which remain unchanged by the
> > proposal -- prove insufficient to the task.
Yes, but the implication was that the existing heuristics would become a
second-class citizen, left to rot, and so in practice would become less
and less used.
> > To wit:
> >
> > On Tue, Nov 17, 2009 at 21:56, Mike Samuel <mikesamuel_at_gmail.com> wrote:
> >>
> >> Subversion treats the following files as [[mergable]]:
> >>
> >> * Files with no svn:mime-type [[and no svn:merge-mode]]
> >> * Files with a svn:mime-type starting "text/"
> >> * Files with a svn:mime-type equal to "image/x-xbitmap"
> >> * Files with a svn:mime-type equal to "image/x-xpixmap"
> >> * [[Files with a svn:merge-mode that is equal to "simple"]]
> >>
> >
> > Furthermore, the need for coordinating autoprops within a team exists
> > without this proposal, independent of issues of merge behavior. I fail
> > to see how the OP's proposal will in any way exacerbate that.
> > I've got about 100 lines of autoprops in the subversion config file I
> > maintain for my team. This is how we try to assure that most of our
> > files get reasonable mime-type, needs-lock, eol-style, from the
> > get-go. Periodically I fix things up with a bash script or two. The
> > need for this won't be affected by the merge-mode proposal.
That's all very well for your team where you have got the management of
auto-props under control. Many people don't use them and so don't have
such a system ready to go.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419549
Received on 2009-11-18 16:28:02 CET