![]() ![]() Scratch_pool=0x929738) at subversion/libsvn_wc/lock.c:95 Local_relpath=0x7fffe7e2b7b0, db=0x0, local_abspath= #0 svn_wc_db_wcroot_parse_local_abspath (wcroot=0x7fffe7e2b7a8, Svn_wc_db_wcroot_parse_local_abspath (wcroot=0x7fffe7e2b7a8, local_relpath=Ġx929d80 "/home/dylan/mm_svn/megamek", result_pool=0x929738, scratch_pool=Ġx929738) at subversion/libsvn_wc/wc_db_wcroot.c:382ģ82 probe_wcroot = apr_hash_get(db->dir_data, local_abspath, I finally got around to installing the debug symbols / devel files for subversion/libsvn and I have a better gdb output, but I still don't know enough about this code right now to debug it further. ![]() #12 0x00007ffff60d90cd in clone () from /lib64/libc.so.6Īt which point I said screw it and moved on to using different software for the moment since I needed to work on my own project instead of trying to debug some arcane mistake that seems to be in libsvn_wc-1.so.0 and not directly in RapidSVN itself. #10 0x00007ffff69829eb in wxThreadInternal::PthreadStart(wxThread*) () #9 ThreadedWorker::Data::Entry (this=0x8201c0) at threaded_worker.cpp:116 Revision=, recurse=true, ignore_externals=false, #6 0x00007ffff7bc6ddc in svn::Client::checkout (this=, url= Program received signal SIGSEGV, Segmentation fault.Ġx00007ffff595514b in svn_wc_db_wcroot_parse_local_abspath () Using host libthread_db library "/lib64/libthread_db.so.1".ĭetaching after fork from child process 2923.ĭetaching after fork from child process 2924.ĭetaching after fork from child process 2925. being a good little programmer myself I've gone and installed the debug symbols. When run in a terminal I also get the same segfault mentioned by the OP. Status window says "Execute Checkout" and then program crashes. In window that pops up I enter my repo URL ( ) file location ( /home/username/mm_svn/megamek ) while leaving all checkboxes at defaultĦ. For me, this is not a common occurrence, and given the choice of a corrupt working copy or losing uncommitted property changes, I tend to opt for the latter.4. One warning: If the working copy contains mixed versions or uncommitted property changes, that information WILL be lost. Since both of the above steps preserve local modifications, there should not be any loss of information (but backing the working copy up before this may nevertheless be a good idea). TortoiseSVN will warn you that you are checking out into an existing folder, but you can go ahead.Īfter this, cleanups, updates and other operations worked without a hitch. TortoiseSVN notices that the destination is the same as the source, and suggests unversioning the working copy.Īfter unversioning, do a fresh checkout into the same folder (which now contains an unversioned copy of all the files you had). In TortoiseSVN, to do an in-place unversioning, right-drag the root folder of the working copy from the file list onto itself in the directory tree, and choose "SVN Export versioned items here" from the pop-up menu. In-place unversioning of the files, and a fresh checkout into the same location, has solved this problem for me. ![]()
0 Comments
Leave a Reply. |