subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Attila Nagy <>
Subject Re: Assertion failed and crash with 1.7.1
Date Thu, 27 Oct 2011 09:38:17 GMT
On 10/27/11 11:28, Stefan Sperling wrote:
> On Thu, Oct 27, 2011 at 10:47:51AM +0200, Attila Nagy wrote:
>> On 10/26/11 15:37, Philip Martin wrote:
>>> Attila Nagy<>   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.
I hope I will never have to do that! :)
BTW, with the current (1.7) WC-implementation, what possible problems do 
you see where this would be needed?
Previously with the per-directory .svn directories it was of course much 
easier, I could checkout the WC and move the .svn directory to its 
original place.
Now I (would) have to do this for all directories...
> 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.
There is no such a thing I guess. I don't care about inodes until they 
don't change on existing files.

>> 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.
Maybe, but I don't know what to index, because it seems to be hard to 
get running SQLite operations out of the system.
>>>> $ 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:
> Is there a symlink in the working copy?
Sure, a lot of them. (I use full operating system copies)
> 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:
> If you apply that patch to your 1.7.1 installation the update
> should succeed.
I could finally resolve the problem with some deletes and svn resolve, 
but that's great to hear!
>> 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'.
Yes, this was the problem.


View raw message