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.
Despite our penchant for self-flaggelation, it seems like we are
forgetting that our current system actually works pretty well for most
cases. 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.
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.
Mark
On Wed, Nov 18, 2009 at 6:31 AM, B Smith-Mannschott
<bsmith.occs_at_gmail.com> wrote:
> (1) It's an ongoing maintenance headache.
> (2) The merge behavior of existing repositories will change,
> surprising some, no doubt.
> (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.
>
>>> 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.
>
> 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.
>
> // Ben
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419498
Received on 2009-11-18 14:22:33 CET