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,
> 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
> Why do we just look at 'mine' for mime_type?
Probably there is no very good reason; that's just how it was originally
> 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.
Received on 2009-11-02 14:55:22 CET