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<b...@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!
