Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E585E9B16 for ; Wed, 5 Oct 2011 20:25:01 +0000 (UTC) Received: (qmail 70905 invoked by uid 500); 5 Oct 2011 20:25:01 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 70873 invoked by uid 500); 5 Oct 2011 20:25:01 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 70866 invoked by uid 99); 5 Oct 2011 20:25:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Oct 2011 20:25:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kyle.leber@gmail.com designates 209.85.213.43 as permitted sender) Received: from [209.85.213.43] (HELO mail-yw0-f43.google.com) (209.85.213.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Oct 2011 20:24:54 +0000 Received: by ywm21 with SMTP id 21so2853192ywm.16 for ; Wed, 05 Oct 2011 13:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gPBn0LZl/uOta1BxypTgZQUVfDHyRK9+lc94rDU0lO8=; b=eIgA7dSXcKXoBYrRg9V33k5Dwwo2YqhwJBTng1bSTF/T/tQaZe/r3bKImMFOeOte9N QyCPb2MH1/TxiQHztK+Tg/YAMAs8elX9ZG63GnMneKsElMX/jgOWlZ+2aAC52pBqxMXf qKlth7/Cd2Uf1X5mDvMf61rMkvw5knX+Ww/kY= MIME-Version: 1.0 Received: by 10.42.62.66 with SMTP id x2mr4295753ich.93.1317846273750; Wed, 05 Oct 2011 13:24:33 -0700 (PDT) Received: by 10.42.220.200 with HTTP; Wed, 5 Oct 2011 13:24:33 -0700 (PDT) In-Reply-To: References: <20111001235546.GA30144@daniel3.local> <20111003000955.GA24599@daniel3.local> <20111003130409.GD21488@ted.stsp.name> Date: Wed, 5 Oct 2011 16:24:33 -0400 Message-ID: Subject: Re: svn merge operation extremely slow From: Kyle Leber To: Johan Corveleyn Cc: Daniel Shahaf , users@subversion.apache.org Content-Type: multipart/alternative; boundary=90e6ba613d7203f71204ae92ff62 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba613d7203f71204ae92ff62 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 3, 2011 at 9:55 AM, Johan Corveleyn wrote: > On Mon, Oct 3, 2011 at 3:04 PM, Stefan Sperling wrote: > > On Mon, Oct 03, 2011 at 02:59:25PM +0200, Johan Corveleyn wrote: > >> On Mon, Oct 3, 2011 at 2:35 PM, Johan Corveleyn > wrote: > >> > On Mon, Oct 3, 2011 at 2:16 PM, Kyle Leber > wrote: > >> >> I set the mime-type to "application/octet-stream" in the working copy > prior > >> >> to merge and this fixed the problem. No more heavy CPU usage or > excessive > >> >> time spent on the file. > >> > > >> > I'm glad it helped. Apart from the performance, it's important that > >> > svn does this merge the "binary way", because as you said line-based > >> > merges are not correct for this file. > >> > >> It may also interest you (and other readers of this thread) that there > >> is an open enhancement request for making text-merges take the same > >> shortcut as binary-merges (if mine == merge-left then set merged := > >> merge-right), to avoid expensive diffing [1]. But that hasn't been > >> addressed yet. > >> > >> > >> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4009 : Big > >> trivial text files merged MUCH slower than binary - pls optimize. > >> > > > > I think we should also file an issue about the problem discussed > > in this thread. svn should take properties on the left/right side of the > > merge into account when determining whether to treat a file as binary. > > I guess it should run the binary merge if any of left, right, or the > > target are marked as binary. > > Yes, maybe you're right. I don't know the specifics / historics of > this behavior (maybe there is a reason for this?). But on the surface > it looks like it should indeed do a binary merge if either one of > left, right or target is marked as binary. > > Even if #4009 would be addressed, it would still make a difference in > the situation where the shortcut-condition (mine == merge-left) > doesn't hold. In that case, I think the "binary-merge" would always > flag a conflict (because it can't do a line-based merge). Is that also > the behavior we want f.i. if only merge-left (or only merge-right) > were marked as binary, and all the other "players" are marked as text? > I guess it's the safest thing to do ... > > -- > Johan > Did someone already file this issue, or do you need me to? I have never done this before, but can certainly make an attempt if this is what's needed. - Kyle --90e6ba613d7203f71204ae92ff62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 3, 2011 at 9:55 AM, Johan Co= rveleyn <jcorvel@= gmail.com> wrote:
On Mon, Oct 3, 2011 at 3:04 PM, Stefan Sp= erling <stsp@elego.de> wrote: > On Mon, Oct 03, 2011 at 02:59:25PM +0200, Johan Corveleyn wrote:
>> On Mon, Oct 3, 2011 at 2:35 PM, Johan Corveleyn <jcorvel@gmail.com> wrote:
>> > On Mon, Oct 3, 2011 at 2:16 PM, Kyle Leber <kyle.leber@gmail.com> wrote:
>> >> I set the mime-type to "application/octet-stream&quo= t; in the working copy prior
>> >> to merge and this fixed the problem.=A0 No more heavy CPU= usage or excessive
>> >> time spent on the file.
>> >
>> > I'm glad it helped. Apart from the performance, it's = important that
>> > svn does this merge the "binary way", because as yo= u said line-based
>> > merges are not correct for this file.
>>
>> It may also interest you (and other readers of this thread) that t= here
>> is an open enhancement request for making text-merges take the sam= e
>> shortcut as binary-merges (if mine =3D=3D merge-left then set merg= ed :=3D
>> merge-right), to avoid expensive diffing [1]. But that hasn't = been
>> addressed yet.
>>
>>
>> [1] http://subversion.tigris.org/issues/show_bug.cgi= ?id=3D4009 : Big
>> trivial text files merged MUCH slower than binary - pls optimize.<= br> >>
>
> I think we should also file an issue about the problem discussed
> in this thread. svn should take properties on the left/right side of t= he
> merge into account when determining whether to treat a file as binary.=
> I guess it should run the binary merge if any of left, right, or the > target are marked as binary.

Yes, maybe you're right. I don't know the specifics / h= istorics of
this behavior (maybe there is a reason for this?). But on the surface
it looks like it should indeed do a binary merge if either one of
left, right or target is marked as binary.

Even if #4009 would be addressed, it would still make a difference in
the situation where the shortcut-condition (mine =3D=3D merge-left)
doesn't hold. In that case, I think the "binary-merge" would = always
flag a conflict (because it can't do a line-based merge). Is that also<= br> the behavior we want f.i. if only merge-left (or only merge-right)
were marked as binary, and all the other "players" are marked as = text?
I guess it's the safest thing to do ...

--
Johan

Did someone already file this issue, or do yo= u need me to?=A0 I have never done this before, but can certainly make an a= ttempt if this is what's needed.

- Kyle
--90e6ba613d7203f71204ae92ff62--