(cross-posting to dev@, please continue to post only on dev@ for this thread)
Todd Gleason wrote:
>
>
> One of our users came across a strange error trying to commit recently
> (with a 1.6 client):
>
>
>
> Action Path Mime type
>
> Command Commit
>
> Error Commit failed (details follow):
>
> Error '.' is not a working copy
>
> Finished!
>
>
>
> On seeing this, you might think the directory he tried to commit had no
> .svn directory. But it did.
>
>
>
> After some investigation, it turned out that the parent directory (which
> was the C:\ root directory) had its own .svn directory. He had
> accidentally done some sort of root-level checkout or move of a .svn
> directory to be under there. I believe the result was that Subversion
> was seeing everything on that drive as not part of the working copy.
> And indeed he couldn’t commit from anything that he believed to be a
> Subversion working copy.
>
>
>
> I understand that it was correct behavior for him to get a failure
> trying to commit, but I wanted to provide this information in case it’s
> helpful to other users, and in case the developers want to change this
> sort of error to be more helpful, for example to indicate something
> about detecting a nested working copy, and including the two directories
> that conflict (the “real” WC root as well as the directory that is
> illegally nested).
>
>
>
> Note that I don’t think this use case will be obsolete even in 1.7
> because I believe there will still be .svn directories directly under
> the WC root.
>
>
>
> --Todd
>
>
>
>
> Please consider the environment before printing this e-mail.
>
> The contents of this e-mail message (including any attachments) are
> confidential to and are intended to be conveyed for the use of the
> recipient to whom it is addressed only. If you receive this transmission
> in error, please notify the sender of this immediately and delete the
> message from your system. Any distribution, reproduction or use of this
> message by someone other than recipient is not authorized and may be
> unlawful.
Todd -- please don't have these mail footers when posting to Subversion
mailing lists. Having this and posting here is a contradiction in terms.
Don't expect us to assume that your footer is obsolete! And please don't say
"it's company policy", because then your company does not allow you to post
here, in which case you shouldn't ;)
About the .svn in the file system root -- technically, svn should only care
about the .svn folder at the current path. Subversion *supports* nested
working copies.
It appears there may be a bug in our "find and lock the current working
copy" code. I can reproduce that having an .svn folder in the file system
root (on a linux) causes a Segmentation Fault upon 'svn status', but *only*
when using trunk. The current 1.6 version does not error, though I did not
try to commit.
Use Subversion trunk to reproduce:
[[[
cd /tmp
svn co http://svn.apache.org/repos/asf/subversion/trunk/notes
sudo cp -a notes/tree-conflicts/.svn /
cd notes/
svn st
[prints "Segmentation fault"]
$ gdb `which svn`
GNU gdb (GDB) 7.0-debian
[...]
(gdb) run st
Starting program: /home/neels/svn/prefix/svn-current/bin/svn st
[Thread debugging using libthread_db enabled]
[New Thread 0xb764eb70 (LWP 3957)]
[Thread 0xb764eb70 (LWP 3957) exited]
Program received signal SIGSEGV, Segmentation fault.
0xb7c6ae42 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
(gdb) bt
#0 0xb7c6ae42 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#1 0xb7d36f42 in ?? () from /usr/lib/libsqlite3.so.0
#2 0xb7d01d82 in sqlite3_mutex_enter () from /usr/lib/libsqlite3.so.0
#3 0xb7d1a1a2 in ?? () from /usr/lib/libsqlite3.so.0
#4 0xb7d0c807 in ?? () from /usr/lib/libsqlite3.so.0
#5 0xb7d209ea in ?? () from /usr/lib/libsqlite3.so.0
#6 0xb7d20c34 in ?? () from /usr/lib/libsqlite3.so.0
#7 0xb7d22790 in ?? () from /usr/lib/libsqlite3.so.0
#8 0xb7d688b5 in ?? () from /usr/lib/libsqlite3.so.0
#9 0xb7d51555 in sqlite3_step () from /usr/lib/libsqlite3.so.0
#10 0xb7dce0b5 in svn_sqlite__step (got_row=0xbf800718, stmt=0x809f1b0)
at subversion/libsvn_subr/sqlite.c:197
#11 0xb7f6ca40 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c90 "/", recurse_depth=74835, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5630
#12 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c88 "/", recurse_depth=74834, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#13 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c80 "/", recurse_depth=74833, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#14 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c78 "/", recurse_depth=74832, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#15 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c70 "/", recurse_depth=74831, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#16 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c68 "/", recurse_depth=74830, scratch_pool=0x80956d8)
at subversion/libsvn_wc/wc_db.c:5645
#17 0xb7f6cbd0 in is_wclocked (locked=0xbfffec24, db=0x80891f0,
local_abspath=0x8285c60 "/", recurse_depth=74829,
[and so on and so on, note "recurse_depth=74829", "=74830", ...]
]]]
Would anyone care to investigate?
~Neels
Received on 2010-02-11 13:54:48 CET