Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of bra@fsn.hu designates
 195.228.252.137 as permitted sender)
Message-ID: <4EA91AB7.7050903@fsn.hu>
Date: Thu, 27 Oct 2011 10:47:51 +0200
From: Attila Nagy <bra@fsn.hu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Philip Martin <philip.martin@wandisco.com>
CC: users@subversion.apache.org
Subject: Re: Assertion failed and crash with 1.7.1
References: <4EA7CC74.5000406@fsn.hu> <87y5w73mcb.fsf@stat.home.lan>
In-Reply-To: <87y5w73mcb.fsf@stat.home.lan>
Content-Type: multipart/alternative;
 boundary="------------040303000005050603020504"

This is a multi-part message in MIME format.
--------------040303000005050603020504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/26/11 15:37, Philip Martin wrote:
> Attila Nagy<bra@fsn.hu>  writes:
>
>> I'm trying to update a working copy of some tens of GBs with svn 1.7.1
> Did you upgrade with 1.7.0 or 1.7.1?
I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm 
currently using.
The upgrade took nearly one week (I can't afford a clean checkout, 
because I have to preserve the files' inode numbers), at the start it 
was running very fast, and at the end of the week it could print a new 
directory in every 8-10 seconds, while the svn processes CPU usage was 100%.
The disks weren't touched, it seems that even with a database completely 
in the OS's buffer cache the SQL operations are pretty slow with a lot 
of files.
Could it be because some indexes are missing (or not optimized for this 
amount of files), or it is what we could get from SQLite?
>
>> $ svn up
>> Updating '.':
>> svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
>> 1582: assertion failed (action == svn_wc_conflict_action_edit ||
>> action == svn_wc_conflict_action_delete || action ==
>> svn_wc_conflict_action_replace)
>> Abort (core dumped)
> Can you show us a gdb stack trace?
I'm sorry, this is a production machine and this error caused a major 
lockup in our business processes, so I've had to work around it, and I 
lost the core file in the process.
BTW, there was one tree conflict somewhere, it seems that an svn resolve 
solved the issue.
>
> How many working nodes do you have?
> sqlite3 .svn/wc.db "select count (*) from nodes where op_depth>  0"
>
The query say that I have one. (now, after the conflict resolution)


--------------040303000005050603020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 10/26/11 15:37, Philip Martin wrote:
    <blockquote class=" cite" id="mid_87y5w73mcb_fsf_stat_home_lan"
      cite="mid:87y5w73mcb.fsf@stat.home.lan" type="cite">
      <pre wrap="">Attila Nagy <a class="moz-txt-link-rfc2396E" href="mailto:bra@fsn.hu">&lt;bra@fsn.hu&gt;</a> writes:

</pre>
      <blockquote class=" cite" id="Cite_24" type="cite">
        <pre wrap="">I'm trying to update a working copy of some tens of GBs with svn 1.7.1
</pre>
      </blockquote>
      <pre wrap="">Did you upgrade with 1.7.0 or 1.7.1?</pre>
    </blockquote>
    I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
    currently using.<br>
    The upgrade took nearly one week (I can't afford a clean checkout,
    because I have to preserve the files' inode numbers), at the start
    it was running very fast, and at the end of the week it could print
    a new directory in every 8-10 seconds, while the svn processes CPU
    usage was 100%.<br>
    The disks weren't touched, it seems that even with a database
    completely in the OS's buffer cache the SQL operations are pretty
    slow with a lot of files.<br>
    Could it be because some indexes are missing (or not optimized for
    this amount of files), or it is what we could get from SQLite?<br>
    <blockquote class=" cite" id="mid_87y5w73mcb_fsf_stat_home_lan"
      cite="mid:87y5w73mcb.fsf@stat.home.lan" type="cite">
      <pre wrap="">

</pre>
      <blockquote class=" cite" id="Cite_25" type="cite">
        <pre wrap="">$ svn up
Updating '.':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
1582: assertion failed (action == svn_wc_conflict_action_edit ||
action == svn_wc_conflict_action_delete || action ==
svn_wc_conflict_action_replace)
Abort (core dumped)
</pre>
      </blockquote>
      <pre wrap="">Can you show us a gdb stack trace?</pre>
    </blockquote>
    I'm sorry, this is a production machine and this error caused a
    major lockup in our business processes, so I've had to work around
    it, and I lost the core file in the process.<br>
    BTW, there was one tree conflict somewhere, it seems that an svn
    resolve solved the issue.<br>
    <blockquote class=" cite" id="mid_87y5w73mcb_fsf_stat_home_lan"
      cite="mid:87y5w73mcb.fsf@stat.home.lan" type="cite">
      <pre wrap="">

How many working nodes do you have?
sqlite3 .svn/wc.db "select count (*) from nodes where op_depth &gt; 0"

</pre>
    </blockquote>
    The query say that I have one. (now, after the conflict resolution)<br>
    <br>
  </body>
</html>

--------------040303000005050603020504--