[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix failing three-way diff for properties

From: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Sat, 7 Nov 2009 20:07:45 +1100

Hi,

Ping. This patch submission has received no further comments / updates.

Gavin.

On 02/11/2009, at 22:13 , Julian Foad wrote:

> Daniel Näslund wrote:
>> I found this comment in svn_wc_conflict_description2_t:
>>
>> [[[
>> /** Whether svn thinks ('my' version of) @c path is a 'binary' file.
>> * (Only if @c kind is 'text', else undefined.) */
>> svn_boolean_t is_binary;
>> ]]]
>>
>> When looking in libsvn_wc/props.c (maybe_generate_propconflict) the
>> is_binary flag and mime_type is handled like this:
>>
>> [[[
>> if (!is_dir && working_props)
>> mime_propval = apr_hash_get(working_props, SVN_PROP_MIME_TYPE,
>> APR_HASH_KEY_STRING);
>> cdesc->mime_type = mime_propval ? mime_propval->data : NULL;
>> cdesc->is_binary = mime_propval ?
>> svn_mime_type_is_binary(mime_propval->data) : FALSE;
>> ]]]
>>
>> So the mime_type and is_binary flag refers to the file the properties
>> belongs to. We were hoping that it would refer to the mime_type of
>> the
>> property.
>>
>> Why do we just look at 'mine' for mime_type?
>
> Probably there is no very good reason; that's just how it was
> originally
> written.
>
>> If 'theirs' is a binary file I guess we still can't do a diff? Or is
>> that a tree conflict?
>
> We still can't do a diff, true. That is not a tree conflict.
>
>> If the mime_type of a file has changed then it's assumed that it's a
>> replaced file.
>
> Where is that assumption coded? It is wrong.
>
>>> I think we have an API for empirically determining whether a certain
>>> file or a certain text contains non-text characters. It is used for
>>> automatically detecting "binary" files during import/add. Maybe you
>>> could use it.
>>
>> Found it! svn_io_detect_mimetype2() was just what I was looking for.
>>
>> BUT it needs a map of mime-types. svn_client_context_t contains one
>> of
>> those. How can I get a hold of that from deep inside libsvn_wc?
>> There is
>> currently 18 stack-levels of merge_report_editor-driven function
>> calls
>> between me and that precious ctx struct!
>
> That function uses the map of MIME types only to recognize filename
> extensions, which is irrelevant for property values. It is optional,
> so
> just pass NULL for that parameter. The function will then just use its
> byte-analysing heuristic which is what you want, I think.
>
> - Julian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413784

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415368
Received on 2009-11-07 10:09:02 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.