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<bra_at_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.
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:
> http://svn.haxx.se/dev/archive-2011-10/0305.shtml
>
> 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:
> http://svn.apache.org/viewvc?view=revision&revision=r1186944
> 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.
Thanks!
Received on 2011-10-27 11:38:54 CEST