subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <jcor...@gmail.com>
Subject Re: svn merge operation extremely slow
Date Mon, 03 Oct 2011 08:10:25 GMT
[ Again: please don't top-post on this list. I'm moving your reply to
the bottom. More below ... ]

On Mon, Oct 3, 2011 at 2:24 AM, Kyle Leber <kyle.leber@gmail.com> wrote:
> On Sun, Oct 2, 2011 at 8:10 PM, Daniel Shahaf <d.s@daniel.shahaf.name>
> wrote:
>>
>> Kyle Leber wrote on Sun, Oct 02, 2011 at 20:05:19 -0400:
>> > Johan,
>> >
>> > I did a little more digging.  There were a few different places where
>> > svn
>> > seems to get hung up so I ran the gprof report on just the first one
>> > (the
>> > merge takes hours otherwise).  In this particular case, svn prints out
>> > that
>> > it is merging from a small text file while it is hanging for more than a
>> > minute @ 100% CPU.  When I examine "lsof", however, it see it actually
>> > has a
>> > different file open.  This one is a large (15 MB) "binary" file.  It
>> > turns
>> > out this binary file did not have a property in the trunk (which I think
>> > means it's treated as text, right?).  But in the branch it was marked as
>> > octet stream.   So perhaps svn is doing a text-based diff on this binary
>> > file because it used to be incorrectly marked as text?
>> >
>>
>> If either side is marked as binary then svn will defer to the "Use
>> merge-right if merge-left == base, else conflict" algorithm.
>>
>> Could you share the value of 'svn proplist --verbose' on both files?
>>
> Yup, trunk version has empty properties
> branch version has:
>
> svn:mime-type
>     application/octet-stream
>

What is the merge target? Is it a trunk working copy (the one without
mime-type), or a branch working copy (with
svn:mime-type=application/octet-stream)?

I think it's the mime-type of the merge target that determines if
merge will take the "binary" route, or the "text" route. See this
snippet from libsvn_wc/merge.c [1] (in the function
svn_wc__internal_merge):

[[[
  /* Decide if the merge target is a text or binary file. */
  if ((mimeprop = get_prop(&mt, SVN_PROP_MIME_TYPE))
      && mimeprop->value)
    is_binary = svn_mime_type_is_binary(mimeprop->value->data);
  else
    {
      const char *value = svn_prop_get_value(mt.actual_props,
                                             SVN_PROP_MIME_TYPE);

      is_binary = value && svn_mime_type_is_binary(value);
    }
]]]

(mt is the merge target)

I'm not terribly familiar with this part of the codebase. But on first
sight, this seems to say:

  (1) Look at the mime-type of the "base version" of the merge target.
If that's binary, then we'll go binary.

  (2) If the "base" of the merge target doesn't have a mime-type, look
if it has one on the "actual" node (the uncommitted local
modifications). If that's binary, then we'll go binary.

  (3) Else: text merge

So I'm guessing that you're merging to trunk, the target without
mime-type property, which makes svn take the "text" route for merging.
Is that correct?

If that's the case, maybe you can simply set the mime-type on that
binary file in your merge target, as a local modification (I don't
think you need to even commit it). Can you try that?

-- 
Johan

[1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_wc/merge.c

Mime
View raw message