On 27 October 2015 at 22:48, Branko Čibej <brane_at_apache.org> wrote:
> On 26.10.2015 16:03, Ivan Zhakov wrote:
>> On 18 September 2015 at 00:00, <rhuijben_at_apache.org> wrote:
>>> Author: rhuijben
>>> Date: Thu Sep 17 21:00:36 2015
>>> New Revision: 1703689
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1703689&view=rev
>>> Log:
>>> Following up on r1703688 fix conflicts reported on merging deletes of
>>> files that have an svn:eol-style 'CR' or 'CRLF' property.
>>>
>> [...]
>>
>>> Modified: subversion/trunk/subversion/libsvn_client/merge.c
>>> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?rev=1703689&r1=1703688&r2=1703689&view=diff
>>> ==============================================================================
>>> --- subversion/trunk/subversion/libsvn_client/merge.c (original)
>>> +++ subversion/trunk/subversion/libsvn_client/merge.c Thu Sep 17 21:00:36 2015
>>> @@ -2349,17 +2349,47 @@ files_same_p(svn_boolean_t *same,
>>> {
>>> svn_stream_t *mine_stream;
>>> svn_stream_t *older_stream;
>>> - svn_opt_revision_t working_rev = { svn_opt_revision_working, { 0 } };
>>> + svn_string_t *special = svn_hash_gets(working_props, SVN_PROP_SPECIAL);
>>> + svn_string_t *eol_style = svn_hash_gets(working_props, SVN_PROP_EOL_STYLE);
>>> + svn_string_t *keywords = svn_hash_gets(working_props, SVN_PROP_KEYWORDS);
>>>
>>> /* Compare the file content, translating 'mine' to 'normal' form. */
>>> - if (svn_prop_get_value(working_props, SVN_PROP_SPECIAL) != NULL)
>>> + if (special != NULL)
>>> SVN_ERR(svn_subst_read_specialfile(&mine_stream, mine_abspath,
>>> scratch_pool, scratch_pool));
>>> else
>>> - SVN_ERR(svn_client__get_normalized_stream(&mine_stream, wc_ctx,
>>> - mine_abspath, &working_rev,
>>> - FALSE, TRUE, NULL, NULL,
>>> - scratch_pool, scratch_pool));
>>> + SVN_ERR(svn_stream_open_readonly(&mine_stream, mine_abspath,
>>> + scratch_pool, scratch_pool));
>>> +
>>> + if (!special && (eol_style || keywords))
>> Hi Bert,
>>
>> Do you know why we do not convert eol style/collapse keywords for
>> special files? I know that it's not related to this commit, but may be
>> you know rationale behind this behavior.
>
> The contents of special files are not user-defined and semantically, the
> contents aren't text but control strings interpreted by the Subversion
> client. There's a pretty good case for not allowing svn:eol-style or
> svn:keywords properties on such files in the first place.
>
This is makes sense. Thanks for the explanation.
--
Ivan Zhakov
Received on 2015-10-30 10:53:03 CET