Mike Samuel wrote:
> 2009/11/17 Martin Furter <mf_at_rola.ch>:
>
>> On Wed, 18 Nov 2009, Branko Cibej wrote:
>>
>>
>>> Mike Samuel wrote:
>>>
>>>> 2009/11/17 Branko Čibej <brane_at_xbc.nu>:
>>>>
>>>>
>>>>> Mike Samuel wrote:
>>>>>
>>>>>
>>>>>> Source code is explicitly not considered human readable.
>>>>>>
>>>>>>
>>>>> Recalling some horrors I've had to review, I even tend to agree ... but
>>>>> it's a strange policy nonetheless. I wonder what kind of rationale they
>>>>> have for it.
>>>>>
>>>>>
>>>> I think making a distinction between human readable content and source
>>>> code is fine. But the distinction was not made consistently from the
>>>> beginning so it's led to confusion.
>>>>
>>>> And if they're going to make such a distinction, usually it helps to
>>>> distinguish between source code that's meant to be read and source
>>>> code for a language that has no separate compilation stage that is
>>>> meant to be delivered to an interpreter. I think this echoes bsmith's
>>>> two flavors of XML in the previous thread.
>>>>
>>>> What do you think of the property name, "svn:merge-mode," and the
>>>> values ("none" "simple")?
>>>>
>>>>
>>> The property name is descriptive enough, so is the "none"; don't have a
>>> quibble there. I do think "simple" is a bit too simple. :) It's a
>>> line-based contextual merge; dunno what would be a better short name for
>>> that, maybe "patch"?
>>>
>> Yeah, I thought the same.
>> What about "line-based"?
>> To me that sounds descriptive enough and not too long :)
>>
>
> Should we collect a bunch of names and put it to a vote?
> So far we have "line-based," "patch," and "simple."
>
I'm not too fond of putting UI design issues to a vote ... it's much
better if everyone just does what I say. :-D
> I guess I can start implementing in the meantime.
>
> Is svn_mime_type_is_binary in subversion/include/svn_types.h the right
> place to start?
>
It is.
> If so, I'll try renaming that
Before you start, I suggest you read:
http://svn.apache.org/repos/asf/subversion/trunk/www/hacking.html
Especially the part about "Release numbering, compatibility and
deprecation." That is a public function, you can't just rename it and
stay within our compatibility guidelines.
> and adding a second merge mode parameter
> and then threading the merge mode through from clients.
>
> I was looking under subversion/tests/libsvn_subr for tests of that
> function, but the word binary doesn't seem to exists anywhere there
> outside comments. Should I just create a new validate_test.c in that
> directory?
>
Try looking at subversion/tests/cmdline: autoprop_tests; blame_tests #2;
commit_tests #3; diff_tests #11, #26; merge_tests #12, #13, #22;
prop_tests #14; svnlook_tests #10; update_tests #1, #2.
Lots of such. :) For the cmdline tests, I suggest adding new ones so
that we continue testing the old behaviour of svn:mime-type without the
new property. Writing specific test s for that ln libsvn_subr would be
really nice, too.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419350
Received on 2009-11-18 08:39:09 CET