2009/11/13 Gavin 'Beau' Baumanis <gavinb_at_thespidernet.com>:
> As the Patch Manager, let me weigh in with the following, please.
>
> It's my role within the project to keep track of "actual" patch proposals and see to it that they don't get lost in amongst all the other mail that goes through the dev list.
> And, primarily for Mike's information, please note that I am not an SVN developer at all, let alone a committer.
>
> I mention that just so you know that I have no vested interest in the outcome, outside of doing everything I can to see patch proposals committed into the trunk.
>
> To that end; (and I'm certainly not "telling you what to do"); instead of withdrawing your proposal - could you not simply change it to be in-line with the agreed view of the community?
> Especially if that view ultimately gives you the end result you require?
> Sure it may not be "your view", it might not be your preferred method of effecting the change required - but think abut it without any emotional attachment for a minute.
>
> 1) Will the community's preferred method of fixing this issue, still fix the issue?
> 2) Will you get the end result you're after?
> 3) Do you have the time to implement the "new" proposal?
>
> Just because it is not "strictly" your proposal - doesn't discount you from completing the required work, if you have the time to donate to the issue.
As I stated before, I am perfectly happy to implement either approach.
> Please don't be "scared off" - the discussion you have just had, I'm sure you can appreciate, happens all the time.
Thanks Gavin. I haven't responded because I'm trying to spend less
time working on the weekend :) I think the level of criticism was
entirely appropriate, and the only reason I kept advocating my
solution (until it finally penetrated my feeble brain that fixing
is-text is not the appropriate goal) is that I'd be wasting the time
people spent understanding my proposal if I stopped advocating it
until it was proven worse than an alternative.
> Don't take it personally.
> The fact that your proposal attracted some 40 odd messages - shows that the community as a whole has a strong interest in seeing the feature completed.
>
> If there is anything I can do for you - or anyone else on the list for that matter - please do not hesitate to ask.
I guess the next step is to flesh out Branko's proposal, and critique that.
I think the open questions include the precise property name, and the
values needed to decide (should-merge?).
It might be worthwhile doing a bit of brainstorming around the kind of
information that might be useful for future merge decisions so that
the two property values needed to fix 1002 aren't confusing in the
context of a new merging system. But we certainly don't need to come
to conclusions before fixing issue 1002.
> Gavin.
>
>
> On 14/11/2009, at 05:46 , Mike Samuel wrote:
>
>> 2009/11/13 Stefan Sperling <stsp_at_elego.de>:
>>> On Fri, Nov 13, 2009 at 08:30:53AM +0100, B. Smith-Mannschott wrote:
>>>> Please give me a property with which I can explicitly communicate my
>>>> intent wrt merging. Please don't munge this information into an
>>>> existing property by trying to interpret extra meaning from it.
>>>>
>>>> As an example of how I've come to feel this way, let's consider XML:
>>>>
>>>> We've got lots of XML files in our repository. Some of them make sense
>>>> to merge (Maven's pom.xml) and some do not (UML models stored in XMI
>>>> format).
>>>
>>> I think this is a very good point.
>>> So "textiness" does not imply "mergeable". A file might contain text
>>> in some character encoding, but a merge tool may not be able to handle
>>> it properly because of the application-level semantics the text represents.
>>> It would just garble the file.
>>>
>>> Mike, I think this is quite important. It means that even just looking
>>> for "text/*" is totally wrong. Extending this flawed mechanism by making
>>> Subversion look for "; charset=" is not gonna help. The subject of this
>>> thread should not be "Classifying files as binary or text" but "How to
>>> determine whether a file is suitable for being merged?".
>>
>> Fair enough. And Branko's suggestion to start small with a property
>> that can be extended from "should merge" to "how to merge" seems wiser
>> given that the merge concern is the only real concern.
>>
>> Please consider my proposal withdrawn.
>>
>>> So I'd favour Branko's proposal, a property which communicates to Subversion
>>> whether file content is suitable to be passed to a diff or merge tool,
>>> regardless of the mime-type. Branko (or anyone else), could you work on
>>> extending this proposal by defining behaviour such as what should happen
>>> when a new file is added (will this property always have to be set manually
>>> or will it be set automatically in some cases?), what should happen if the
>>> property is set on merge-left but not on merge-right or on the merge target,
>>> and whatever other corner-cases we can think of?
>>> A new file in notes/ would be nice :)
>>>
>>> The svn:mime-type property still has its place, e.g. it is useful
>>> whenever a specific mime-type should be sent to a web browser browsing
>>> a Subversion repository. But I agree with deprecating its use to detect
>>> "mergeability".
>>
>>> Stefan
>>>
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417693
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418307
Received on 2009-11-16 02:37:26 CET