Re: Any way to avoid working copy locks?
On Wed, Mar 16, 2011 at 6:02 AM, Douglas Pearson wrote: > During an "svn update" or "svn commit" my understanding of SVN is that it > walks the local folder tree, placing some sort of lock file within each .svn > folder. > > The operation is then executed and at the end, the locks are removed. Hence > the need for the "clean up" command if the operation crashes for some > reason. I assume this is done to ensure that you can't corrupt your working > copy by running two operations at the same time on the same working copy - > with no doubt disastrous results. Seems reasonable. > > My question - is there any way to run without those local locks? > > We have a really big folder tree (~5GB of data and ~100,000 files in a huge > number of folders). Currently the time spent locking and unlocking the tree > significantly dwarfs the time spent working on the tree (we normally are > only changing a tiny fraction of this data). So for automatic (non-human > controlled) tools using SVN it would be nice to disable the locking, so > updates and commits were faster. For the developers out there, think > continuous integration server. We'd be happy to take on the risk that if we > ran two commands at once we've blow up our working copy. That's pretty easy > to guarantee never happens with a single lock around the whole process. > > Anything we can do to get this speed up? > > Thanks, > > Doug > > P.S. Please include me directly in any replies. I'm not currently > subscribed to this list. You are right, the locking of big trees in a Subversion working copy is very expensive, especially on Windows and/or on network filesystems (NFS, CIFS, ...). See this issue in the issue tracker: http://subversion.tigris.org/issues/show_bug.cgi?id=3369 (Locking strategy inadequate for decent Windows Performance) (you may be able to achieve better performance on *nix operating systems, with a filesystem that's fast with small files, and with a fast local disk (SSD if you want the max, but a 10k rpm disk should also be pretty good), YMMV) The bad news is: no, you can't really disable this right now. The good news is: this issue should go away with the upcoming 1.7 release, which contains a complete rewrite of the working copy system. It may still take a couple of months before it's released, but it will definitely be worth it :-). Cheers, -- Johan
Re: Failed SVN Verify Logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-16 00:38, Jules Herr wrote: [...] > hotcopy completed, failure with snvadmin verify on revision 607 in both > the old repository and and the newly created hotcopied repository. [...] Jules, you should probably try fsfsverify. Be sure to run it on a copy of your repository. You may have to run the repair step repeatedly before it converges. http://www.szakmeister.net/fsfsverify/ http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2AoYkACgkQcEKlWnqVgz3oiQCfW9kycVoyNVtNm7XLl+4EUi+E aZQAoInT4Cwb+CCBQTfZNL1ErIcZO4VT =sOGc -END PGP SIGNATURE-
Re: Any way to avoid working copy locks?
On Wed, Mar 16, 2011 at 5:02 AM, Johan Corveleyn wrote: > You are right, the locking of big trees in a Subversion working copy > is very expensive, especially on Windows and/or on network filesystems > (NFS, CIFS, ...). See this issue in the issue tracker: It's at least an order of magnitude worse on CIFS. I've found NFS performance to be at least comparable to local file system performance. I'd hoped that upgrades to using SMB2 would help with this, but so far it hasn't helped noticeably.
Re: commit not validated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-07 17:28, Bastien Semene wrote: > I'd like to know if it is possible to commit code not updatable (not > validated) until a flag is set/unset ? > > > Here is our problem : > We have projects with source code and datas, and a buildmachine build > the executable(s). > > At time 0 the code is commited, the buildmachine starts building. > At time + X (X >= 0) new data model is commited. > At time + Y (Y > X) compilation is successfull and the new data can be > read/write by the executable. > > During time Y-X, the project is broken as the old executable can't read > new datas. > I wish to let people - data or source code providers - commit while they > cannot automatically update these revisions (they can force it, the > buildmachine for example needs new source code if something fails during > the previous build). > > Something like "not validated" commits can be an answser, but I didn't > see anything allowing this on SVN. > I've thought to some other durty solutions, but I'd like to be sure > there's no clean way before starting anything. Bastien, JetBrains have a feature in their TeamCity continuous integration & build management solution that might be of interest to you. Blurb from their product description: Pre-Tested Commit: No broken code in your version control. Ever. Typically, your team submits code to Version Control BEFORE verifying that it works, and risks breaking the build every single time — causing more problems than necessary. That's why TeamCity is different. Unlike the standard scenario (edit, commit, verify), TeamCity's Pre-tested Commit feature allows you to remotely verify your changes BEFORE committing them to the VCS. If your changes pass, TeamCity (in cooperation with your IDE) AUTOMATICALLY commits them to Version Control. If they fail, your code won't be submitted to the VCS and you'll receive a notification (by email, IM, your Windows System Tray, or in your IDE), allowing you to fix the failed code immediately. And unlike the standard scenario, you'll always know WHO broke the code. Most importantly, your team never stops working and there is never broken code in your Version Control. http://www.jetbrains.com/teamcity/features/delayed_commit.html - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Aw7IACgkQcEKlWnqVgz3VaQCgr/BtgUc4n9l9cYNLJLEdoDjo t7AAni8Nvxec9KyD98C8psvqM0yHERzb =qmx9 -END PGP SIGNATURE-
Re: commit not validated
The problem is not with broken code, it is with old executables trying to read new data structure. There's no build fail. The local user successfully build & run, and idem for the buildmachine(s). The problem is for people working locally on data, not on the source code. "Simply" working on branches would change the workflow in a big time-consuming factory. Le 16/03/2011 15:05, Michael Diers a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-07 17:28, Bastien Semene wrote: I'd like to know if it is possible to commit code not updatable (not validated) until a flag is set/unset ? Here is our problem : We have projects with source code and datas, and a buildmachine build the executable(s). At time 0 the code is commited, the buildmachine starts building. At time + X (X>= 0) new data model is commited. At time + Y (Y> X) compilation is successfull and the new data can be read/write by the executable. During time Y-X, the project is broken as the old executable can't read new datas. I wish to let people - data or source code providers - commit while they cannot automatically update these revisions (they can force it, the buildmachine for example needs new source code if something fails during the previous build). Something like "not validated" commits can be an answser, but I didn't see anything allowing this on SVN. I've thought to some other durty solutions, but I'd like to be sure there's no clean way before starting anything. Bastien, JetBrains have a feature in their TeamCity continuous integration& build management solution that might be of interest to you. Blurb from their product description: Pre-Tested Commit: No broken code in your version control. Ever. Typically, your team submits code to Version Control BEFORE verifying that it works, and risks breaking the build every single time — causing more problems than necessary. That's why TeamCity is different. Unlike the standard scenario (edit, commit, verify), TeamCity's Pre-tested Commit feature allows you to remotely verify your changes BEFORE committing them to the VCS. If your changes pass, TeamCity (in cooperation with your IDE) AUTOMATICALLY commits them to Version Control. If they fail, your code won't be submitted to the VCS and you'll receive a notification (by email, IM, your Windows System Tray, or in your IDE), allowing you to fix the failed code immediately. And unlike the standard scenario, you'll always know WHO broke the code. Most importantly, your team never stops working and there is never broken code in your Version Control. http://www.jetbrains.com/teamcity/features/delayed_commit.html - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Aw7IACgkQcEKlWnqVgz3VaQCgr/BtgUc4n9l9cYNLJLEdoDjo t7AAni8Nvxec9KyD98C8psvqM0yHERzb =qmx9 -END PGP SIGNATURE- -- Bastien Semene Administrateur Réseau& Système Cyanide Studio - FRANCE
[svn] subversion crash report
Subversion crashed on my machine, and instructed me to send this crash log. -- Darryl Fenwick Streamsim Technologies, Inc 650 557 2196 Process info: Cmd line: svn up trunk Version: 1.6.15 (r1038135), compiled Nov 24 2010, 15:10:31 Platform: Windows OS version 6.1 build 7600 Exception: ACCESS_VIOLATION Registers: eax=02e493b8 ebx=0003 ecx= edx= esi=01fb2ea8 edi= eip=002cb397 esp=0018f680 ebp= efl=00010246 cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b Stacktrace: #1 0x002cb397 in svn_dirent_is_child () Loaded modules: 0x0040 C:\Program Files (x86)\CollabNet\Subversion Client\svn.exe (1.6.15.55095, 155648 bytes) 0x77d4 C:\Windows\SysWOW64\ntdll.dll (6.1.7600.16695, 1572864 bytes) 0x769b C:\Windows\SysWOW64\kernel32.dll (6.1.7600.16385, 1048576 bytes) 0x75a8 C:\Windows\SysWOW64\KERNELBASE.dll (6.1.7600.16385, 286720 bytes) 0x6eec C:\Program Files (x86)\CollabNet\Subversion Client\libapr-1.dll (1.4.2.0, 139264 bytes) 0x7780 C:\Windows\SysWOW64\advapi32.dll (6.1.7600.16385, 655360 bytes) 0x7591 C:\Windows\SysWOW64\msvcrt.dll (7.0.7600.16385, 704512 bytes) 0x759c C:\Windows\SysWOW64\sechost.dll (6.1.7600.16385, 102400 bytes) 0x771c C:\Windows\SysWOW64\rpcrt4.dll (6.1.7600.16385, 983040 bytes) 0x758b C:\Windows\SysWOW64\sspicli.dll (6.1.7600.16484, 393216 bytes) 0x758a C:\Windows\SysWOW64\CRYPTBASE.dll (6.1.7600.16385, 49152 bytes) 0x7790 C:\Windows\SysWOW64\ws2_32.dll (6.1.7600.16385, 217088 bytes) 0x76c5 C:\Windows\SysWOW64\nsi.dll (6.1.7600.16385, 24576 bytes) 0x7402 C:\Windows\System32\mswsock.dll (6.1.7600.16385, 245760 bytes) 0x772b C:\Windows\SysWOW64\user32.dll (6.1.7600.16385, 1048576 bytes) 0x7692 C:\Windows\SysWOW64\gdi32.dll (6.1.7600.16385, 589824 bytes) 0x75a7 C:\Windows\SysWOW64\lpk.dll (6.1.7600.16385, 40960 bytes) 0x7672 C:\Windows\SysWOW64\usp10.dll (1.626.7600.16385, 643072 bytes) 0x75ad C:\Windows\SysWOW64\shell32.dll (6.1.7600.16644, 12881920 bytes) 0x778a C:\Windows\SysWOW64\shlwapi.dll (6.1.7600.16385, 356352 bytes) 0x1000 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_client-1.dll (1.6.15.55095, 204800 bytes) 0x6ee6 C:\Program Files (x86)\CollabNet\Subversion Client\libaprutil-1.dll (1.3.9.0, 192512 bytes) 0x6ee5 C:\Program Files (x86)\CollabNet\Subversion Client\libapriconv-1.dll (1.2.1.0, 36864 bytes) 0x002a C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_delta-1.dll (1.6.15.55095, 90112 bytes) 0x002c C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_subr-1.dll (1.6.15.55095, 716800 bytes) 0x74b2 C:\Windows\System32\shfolder.dll (6.1.7600.16385, 20480 bytes) 0x7762 C:\Windows\SysWOW64\ole32.dll (6.1.7600.16624, 1425408 bytes) 0x7750 C:\Windows\SysWOW64\crypt32.dll (6.1.7600.16385, 1163264 bytes) 0x7741 C:\Windows\SysWOW64\msasn1.dll (6.1.7600.16415, 49152 bytes) 0x0003 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_diff-1.dll (1.6.15.55095, 53248 bytes) 0x0037 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_ra-1.dll (1.6.15.55095, 520192 bytes) 0x0043 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_repos-1.dll (1.6.15.55095, 139264 bytes) 0x0046 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_fs-1.dll (1.6.15.55095, 135168 bytes) 0x005a C:\Program Files (x86)\CollabNet\Subversion Client\libeay32.dll (1.0.0.2, 1286144 bytes) 0x006e C:\Program Files (x86)\CollabNet\Subversion Client\ssleay32.dll (1.0.0.2, 245760 bytes) 0x74db C:\Windows\System32\secur32.dll (6.1.7600.16484, 32768 bytes) 0x0072 C:\Program Files (x86)\CollabNet\Subversion Client\libsasl.dll (2.1.23.0, 77824 bytes) 0x0074 C:\Program Files (x86)\CollabNet\Subversion Client\libsvn_wc-1.dll (1.6.15.55095, 217088 bytes) 0x774a C:\Windows\System32\imm32.dll (6.1.7600.16385, 393216 bytes) 0x767c C:\Windows\SysWOW64\msctf.dll (6.1.7600.16385, 835584 bytes) 0x73e2 C:\Windows\System32\profapi.dll (6.1.7600.16385, 45056 bytes) 0x730e C:\Windows\System32\uxtheme.dll (6.1.7600.16385, 524288 bytes) 0x72cc C:\Windows\System32\security.dll (6.1.7600.16385, 12288 bytes) 0x6daf C:\Windows\System32\credssp.dll (6.1.7600.16385, 32768 bytes) 0x6af8 C:\Windows\SysWOW64\msv1_0.dll (6.1.7600.16420, 270336 bytes) 0x6cc8 C:\Windows\System32\cryptdll.dll (6.1.7600.16385, 69632 bytes) 0x73ca C:\Windows\System32\cryptsp.dll (6.1.7600.16385, 90112 bytes) 0x73c6 C:\Windows\System32\rsaenh.dll (6.1.7600.16385, 241664 bytes) 0x6a88 C:\Windows\System32\cryptui.dll (6.1.7600.16385, 1015808 bytes) 0x7406 C:\Windows\System32\nlaapi.dll (6.1.7600.16385, 65536 bytes) 0x73f1 C:\Windows\System32\dnsapi.dll (6.1.7600.16385, 278528 bytes) 0x73f0 C:\Windows\System32\winrnr.dll (6.1.7600.16385, 32768 bytes) 0x73ef C:\Windows\System32\NapiNSP.dll (6.1.7600.16385, 65536 b
Re: Failed SVN Verify Logs
Hi Michael, Ankush and everyone else involved, thanks for you help and suggestions to date. I will continue attempting to solve this issue until we reach a resolution. Attempted to run fsfsverify.py on my hotcopied version of the repository. No success. Output is included below: C:\fsfsverify\fsfsverify>fsfsverify.py -f Z:/hotcopy_314/db/revs/607 NodeRev Id: 0.0.r607/16044 type: dir pred: 0.0.r606/7312599 text: PLAIN 607 15924 107 107 2cfb1cc2b14944cc284371f567e7b3d7 cpath: / copyroot: 0 / dir contents: kits: [dir, 7f.0.r553/463] code: [dir, 2.6.r607/15771] internal: [dir, 2tj.0.r582/6535] NodeRev Id: 2.6.r607/15771 type: dir pred: 2.6.r606/7312320 text: PLAIN 607 15274 484 484 af645977d85c473effc75e62415404cc cpath: /code copyroot: 24 /code dir contents: vitalsigns: [dir, 1cg.6.r161/5569] omnibus: [dir, 3.8.r524/547] PWC_TESTs: [dir, 15r1.6.r406/225055] IFS_CD: [dir, 9on.6.r429/352] custom: [dir, 1pj.6.r604/173783] omnibus6: [dir, 170o.6.r607/15109] IBM_Tests: [dir, 15rg.6.r502/189119] CorporateWeb: [dir, 3kp.6.r297/16099] omnibusLicense: [dir, 3at.6.r234/5577] omnibusClient: [dir, 36p.6.r206/128653] ISG: [dir, 15v8.6.r573/50408] ISG30: [dir, 2u9.6.r605/5046929] NodeRev Id: 170o.6.r607/15109 type: dir pred: 170o.6.r606/7311655 text: PLAIN 607 15023 73 73 df8dc903c331da7f17bd89e00ab21185 cpath: /code/omnibus6 copyroot: 24 /code dir contents: trunk: [dir, 170p.6.r607/14850] tags: [dir, 170q.6.r540/0] NodeRev Id: 170p.6.r607/14850 type: dir pred: 170p.6.r606/7311394 text: PLAIN 607 14649 188 188 b292ec37f07809f3fc66c862cd21a3bc cpath: /code/omnibus6/trunk copyroot: 24 /code dir contents: docs: [dir, 170r.6.r584/3288457] src: [dir, 18x7.6.r607/14475] build: [dir, 18x5.6.r607/8223] lib: [dir, 18x6.6.r606/7305608] proto: [dir, 18vh.6.r574/436101] NodeRev Id: 18x7.6.r607/14475 type: dir pred: 18x7.6.r606/7311013 text: PLAIN 607 14422 40 40 13883f96e91486214b854ab68fbcc75e cpath: /code/omnibus6/trunk/src copyroot: 24 /code dir contents: java: [dir, 18x8.6.r607/14243] NodeRev Id: 18x8.6.r607/14243 type: dir pred: 18x8.6.r606/7310778 text: PLAIN 607 14191 39 39 19c447f0e8f1f62b71d0d08256f47ec4 cpath: /code/omnibus6/trunk/src/java copyroot: 24 /code dir contents: com: [dir, 18x9.6.r607/14008] NodeRev Id: 18x9.6.r607/14008 type: dir pred: 18x9.6.r606/7310540 text: PLAIN 607 13957 38 38 9ba5ae313eb96f2ab3c7a3303842597b cpath: /code/omnibus6/trunk/src/java/com copyroot: 24 /code dir contents: kx: [dir, 18xa.6.r607/13771] NodeRev Id: 18xa.6.r607/13771 type: dir pred: 18xa.6.r606/7310300 text: PLAIN 607 13715 43 43 cb878d2ac9f070ac2bf9ef20becf9c0f cpath: /code/omnibus6/trunk/src/java/com/kx copyroot: 24 /code dir contents: omnibus: [dir, 18xb.6.r607/13519] NodeRev Id: 18xb.6.r607/13519 type: dir pred: 18xb.6.r606/7310045 text: PLAIN 607 13355 151 151 23b0fc71e626efa615cd4e322af78693 cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus copyroot: 24 /code dir contents: lmssvc: [dir, 18xg.6.r607/12655] test: [dir, 18xh.6.r607/8677] domain: [dir, 18xc.6.r607/11493] util: [dir, 18xi.6.r607/13156] NodeRev Id: 18xg.6.r607/12655 type: dir pred: 18xg.6.r606/7309403 text: PLAIN 607 12491 151 151 c48b9cd7aef9cfd18f0dd38ee11e8f4f cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc copyroot: 24 /code dir contents: LoginResult.java: [file, 18xo.31!.r607/12197] Auditor.java: [file, 18xn.6.r607/11981] LoginSvc.java: [file, 18y0.31".r607/11696] NodeRev Id: 18xo.31!.r607/12197 type: file pred: 18xo.31∟.r606/7308929 text: UNKNOWN 584 2404 840 1982 1701913b5499bee7137e4d59b39de6f2 cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc/LoginResult.java copyfrom: 606 /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc/LoginResult.j ava-KEEP Skipping text rep since it isn't present in the current rev NodeRev Id: 18xn.6.r607/11981 type: file pred: 18xn.6.r584/3285690 text: DELTA 607 2223 55 1046 da04f16447a1d0819af36c53974040e6 cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc/Auditor.java copyroot: 24 /code NodeRev Id: 18y0.31".r607/11696 type: file pred: 18y0.31↔.r606/7308645 text: DELTA 607 0 333 4113 ba96b8ca73ded9af13ae14ffa6f22015 cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc/LoginSvc.java copyfrom: 606 /code/omnibus6/trunk/src/java/com/kx/omnibus/lmssvc/LoginSvc.java -KEEP NodeRev Id: 18xh.6.r607/8677 type: dir pred: 18xh.6.r606/7306066 text: PLAIN 607 8614 50 50 ac87d243a772a0bafd4bd56d3ec19cea cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/test copyroot: 24 /code dir contents: UserTest.java: [file, 18y2.6.r607/8399] NodeRev Id: 18y2.6.r607/8399 type: file pred: 18y2.6.r606/7305784 text: DELTA 607 815 1001 6522 20d9283d756f0ac65e7295a7216c5d63 cpath: /code/omnibus6/trunk/src/java/com/kx/omnibus/test/UserTest.java copyroot: 24 /code NodeRev Id: 18xc.6.r607/11493 type: dir pred: 18xc.6.r606/7308441 text: PLAIN 607 11364 11
Compiling subversion 1.6.16
Hi, all I am trying to compile subversion 1.6.16. autogen.sh does not report any problem. I then run configure: # ./configure --with-apxs=$APACHE/bin/apxs --with-apr=$APACHE/bin/ --with-apr-util=$APACHE/bin/ --with-zlib=/usr/local . checking whether to look for SASL... yes configure: Looking in default locations checking sasl/sasl.h usability... no checking sasl/sasl.h presence... yes configure: WARNING: sasl/sasl.h: present but cannot be compiled configure: WARNING: sasl/sasl.h: check for missing prerequisite headers? configure: WARNING: sasl/sasl.h: see the Autoconf documentation configure: WARNING: sasl/sasl.h: section "Present But Cannot Be Compiled" configure: WARNING: sasl/sasl.h: proceeding with the compiler's result configure: WARNING: ## ## configure: WARNING: ## Report this to http://subversion.tigris.org/ ## configure: WARNING: ## ## checking for sasl/sasl.h... no checking for sasl/sasl.h... (cached) no checking for availability of Cyrus SASL v2... no checking for Mac OS KeyChain Services... no checking whether APR has support for DSOs... yes checking whether to look for GNOME Keyring... no checking for msgfmt... /usr/local/bin/msgfmt checking for msgmerge... /usr/local/bin/msgmerge checking for xgettext... /usr/local/bin/xgettext checking for library containing bindtextdomain... no checking for library containing bindtextdomain... no configure: WARNING: bindtextdomain() not found. Disabling NLS. checking whether to look for KWallet... no checking for ANSI C header files... (cached) no checking for an ANSI C-conforming const... no checking for size_t... no checking for working memcmp... no checking for vprintf... no checking for symlink... no checking for readlink... no configure: zlib library configuration checking zlib.h usability... no checking zlib.h presence... yes configure: WARNING: zlib.h: present but cannot be compiled configure: WARNING: zlib.h: check for missing prerequisite headers? configure: WARNING: zlib.h: see the Autoconf documentation configure: WARNING: zlib.h: section "Present But Cannot Be Compiled" configure: WARNING: zlib.h: proceeding with the compiler's result configure: WARNING: ## ## configure: WARNING: ## Report this to http://subversion.tigris.org/ ## configure: WARNING: ## ## checking for zlib.h... no configure: error: subversion requires zlib The SASL (v2.1.23) and zlib (v1.2.5) are installed at default location (/usr/local). I read the "autoconf" document at mentioned web site but don't know how to make a header file change. Can anyone help me? Thanks in advance. Ryan Jiang This message (including any attachments) is intended solely for the specific individual(s) or entity(ies) named above, and may contain legally privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, by other than the intended recipient, is strictly prohibited.
Re: [svn] subversion crash report
On Mar 16, 2011, at 10:08, Darryl Fenwick wrote: > Subversion crashed on my machine, and instructed me to send this crash log. What actions preceded that crash?
Re: Any way to avoid working copy locks?
Thanks for the responses and good to know this is an issue that's being worked on. We'll look forward to 1.7 eagerly! Dou On Wed, Mar 16, 2011 at 2:02 AM, Johan Corveleyn wrote: > On Wed, Mar 16, 2011 at 6:02 AM, Douglas Pearson > wrote: > > During an "svn update" or "svn commit" my understanding of SVN is that it > > walks the local folder tree, placing some sort of lock file within each > .svn > > folder. > > > > The operation is then executed and at the end, the locks are removed. > Hence > > the need for the "clean up" command if the operation crashes for some > > reason. I assume this is done to ensure that you can't corrupt your > working > > copy by running two operations at the same time on the same working copy > - > > with no doubt disastrous results. Seems reasonable. > > > > My question - is there any way to run without those local locks? > > > > We have a really big folder tree (~5GB of data and ~100,000 files in a > huge > > number of folders). Currently the time spent locking and unlocking the > tree > > significantly dwarfs the time spent working on the tree (we normally are > > only changing a tiny fraction of this data). So for automatic (non-human > > controlled) tools using SVN it would be nice to disable the locking, so > > updates and commits were faster. For the developers out there, think > > continuous integration server. We'd be happy to take on the risk that if > we > > ran two commands at once we've blow up our working copy. That's pretty > easy > > to guarantee never happens with a single lock around the whole process. > > > > Anything we can do to get this speed up? > > > > Thanks, > > > > Doug > > > > P.S. Please include me directly in any replies. I'm not currently > > subscribed to this list. > > You are right, the locking of big trees in a Subversion working copy > is very expensive, especially on Windows and/or on network filesystems > (NFS, CIFS, ...). See this issue in the issue tracker: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3369 (Locking > strategy inadequate for decent Windows Performance) > > (you may be able to achieve better performance on *nix operating > systems, with a filesystem that's fast with small files, and with a > fast local disk (SSD if you want the max, but a 10k rpm disk should > also be pretty good), YMMV) > > The bad news is: no, you can't really disable this right now. > > The good news is: this issue should go away with the upcoming 1.7 > release, which contains a complete rewrite of the working copy system. > It may still take a couple of months before it's released, but it will > definitely be worth it :-). > > Cheers, > -- > Johan >
Re: subversion crash report
On Mar 16, 2011, at 14:20, Darryl Fenwick wrote: > Apologies for the non-descriptive e-mail previously. I was either updating > or committing, I'm don't remember. Sorry - not very helpful perhaps. > > My subversion (version 1.6.15) on my 64-bit windows 7 machine has been > unstable. I get a lot of complaints about not being able to copy files from > the tmp directory, etc, when I try to update. > > If you wish, I can continue to send you more information if ever I encounter > problems. Let me know. > > Darryl If you have further information to add, please do send it, but to the list, not to me personally. I'm Cc'ing the list on this reply again.
Re: subversion crash report
On Wed, Mar 16, 2011 at 11:08 PM, Ryan Schmidt wrote: > > On Mar 16, 2011, at 14:20, Darryl Fenwick wrote: > > > Apologies for the non-descriptive e-mail previously. I was either updating > > or committing, I'm don't remember. Sorry - not very helpful perhaps. You were updating your trunk working copy, says so at the top of the log file: Process info: Cmd line: svn up trunk Is that trunk folder located directory under the root of a drive? Based on the code in svn_dirent_is_child(), this might be related to: http://subversion.tigris.org/issues/show_bug.cgi?id=3795 > > > My subversion (version 1.6.15) on my 64-bit windows 7 machine has been > > unstable. I get a lot of complaints about not being able to copy files > > from the tmp directory, etc, when I try to update. > > What type of complaints? > > If you wish, I can continue to send you more information if ever I > > encounter problems. Let me know. > > > > Darryl > > If you have further information to add, please do send it, but to the list, > not to me personally. I'm Cc'ing the list on this reply again. > Lieven
