subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Assertion failed and crash with 1.7.1
Date Thu, 27 Oct 2011 09:28:31 GMT
On Thu, Oct 27, 2011 at 10:47:51AM +0200, Attila Nagy wrote:
> 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),

This is an interesting use case, but please keep in mind that this
is not a normal use case for Subversion. Checkouts are considered
disposable. There are scenarios where getting a new checkout is the
best way to replace a broken working copy.

You will have your reasons for using Subversion this way, but if you
care about inode numbers you might want to look into tools that know
more about internals of the filesystem you are using and preserve
inode information.

> 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%.

This sounds like a linear table scan. There might be room for
optimisation by adding another index.

> >>$ 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,

I'm sorry to hear that.

This assertion you ran into looks exactly like the one reported here:
http://svn.haxx.se/dev/archive-2011-10/0305.shtml

Is there a symlink in the working copy?
If so this is a known regression with updating symlinks. A fix was made
and is scheduled for release in 1.7.2.
The fix was committed in this revision:
http://svn.apache.org/viewvc?view=revision&revision=r1186944
If you apply that patch to your 1.7.1 installation the update
should succeed.

> 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.

The tree conflict was probably flagged because of the above bug.
It is spurious and can be removed via 'svn resolve'.

Mime
View raw message