From dev-return-1856-daniel=haxx.se@subversion.apache.org Thu Feb 11 13:54:48 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o1BCsl87006974 for ; Thu, 11 Feb 2010 13:54:48 +0100 Received: (qmail 25232 invoked by uid 500); 11 Feb 2010 12:54:42 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 25214 invoked by uid 99); 11 Feb 2010 12:54:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 12:54:42 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 12:54:33 +0000 X-Envelope-From: neels@elego.de Received: from [192.168.0.110] (p57A0F716.dip.t-dialin.net [87.160.247.22]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id o1BCs3Qt029674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Feb 2010 13:54:04 +0100 Message-ID: <4B73FDEB.8060603@elego.de> Date: Thu, 11 Feb 2010 13:54:03 +0100 From: Neels J Hofmeyr Organization: elego Software Solutions GmbH User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Todd Gleason CC: "users@subversion.apache.org" , dev@subversion.apache.org Subject: WC in file system root -- was: Re: '.' is not a working copy error and resolution (on users@) References: <6F673D579568B84096D6CFB501E951C2134FCAC16D@USSJSEXMB01.int.elekta.com> In-Reply-To: <6F673D579568B84096D6CFB501E951C2134FCAC16D@USSJSEXMB01.int.elekta.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=5862EA90 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26158F81F35295D301C193D9" X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 --------------enig26158F81F35295D301C193D9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (cross-posting to dev@, please continue to post only on dev@ for this thr= ead) Todd Gleason wrote: >=20 >=20 > One of our users came across a strange error trying to commit recently > (with a 1.6 client): >=20 > =20 >=20 > Action Path Mime typ= e >=20 > Command Commit >=20 > Error Commit failed (details follow): >=20 > Error '.' is not a working copy >=20 > Finished! >=20 > =20 >=20 > On seeing this, you might think the directory he tried to commit had no= > .svn directory. But it did. >=20 > =20 >=20 > After some investigation, it turned out that the parent directory (whic= h > 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.=20 > And indeed he couldn=E2=80=99t commit from anything that he believed to= be a > Subversion working copy. >=20 > =20 >=20 > 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=E2= =80=99s > 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 directorie= s > that conflict (the =E2=80=9Creal=E2=80=9D WC root as well as the direct= ory that is > illegally nested). >=20 > =20 >=20 > Note that I don=E2=80=99t 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. >=20 > =20 >=20 > --Todd >=20 > =20 >=20 >=20 > Please consider the environment before printing this e-mail. >=20 > 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 transmissio= n > 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 po= st here, in which case you shouldn't ;) About the .svn in the file system root -- technically, svn should only ca= re 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 *onl= y* when using trunk. The current 1.6 version does not error, though I did no= t 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= =2E0 #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=3D0xbf800718, stmt=3D0x809f1b= 0) at subversion/libsvn_subr/sqlite.c:197 #11 0xb7f6ca40 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c90 "/", recurse_depth=3D74835, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5630 #12 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c88 "/", recurse_depth=3D74834, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5645 #13 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c80 "/", recurse_depth=3D74833, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5645 #14 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c78 "/", recurse_depth=3D74832, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5645 #15 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c70 "/", recurse_depth=3D74831, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5645 #16 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c68 "/", recurse_depth=3D74830, scratch_pool=3D= 0x80956d8) at subversion/libsvn_wc/wc_db.c:5645 #17 0xb7f6cbd0 in is_wclocked (locked=3D0xbfffec24, db=3D0x80891f0, local_abspath=3D0x8285c60 "/", recurse_depth=3D74829, [and so on and so on, note "recurse_depth=3D74829", "=3D74830", ...] ]]] Would anyone care to investigate? ~Neels --------------enig26158F81F35295D301C193D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAktz/esACgkQCXRUkVhi6pC1aACfR3zuUTLJCmSwg5Z/hXXhgDIA gfkAoMx7nwdq1MOsuRYx5DnnrkmMEkjm =dOl8 -----END PGP SIGNATURE----- --------------enig26158F81F35295D301C193D9--