fsfs rep on Win98SE lock file problem

Hello, I was happy to learn (from the svn FAQ) that the fsfs backend would support repositories on Win98. I want to create repositories on Win98SE for local, personal use (not for running a server). However, both the svn 1.1.0 client (binaries from the svn site; tried both the .zip and the .exe) and TortoiseSVN 1.1.0 (build 1769) give a problem. The fsfs repository creation goes okay. But the first checkout after that gives a `shared lock' problem on db.lock. Here is a transcript of the problem: ---------------------------------------------------------------------- C:\tmp > svnadmin --version svnadmin, version 1.1.0 (r11180) compiled Oct 4 2004, 21:11:18 Copyright (C) 2000-2004 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). C:\tmp > svn --version svn, version 1.1.0 (r11180) compiled Oct 4 2004, 21:11:18 Copyright (C) 2000-2004 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema C:\tmp > svnadmin create --fs-type=fsfs root C:\tmp > mkdir work C:\tmp > cd work C:\tmp\work > svn co file:///c:/tmp/root svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///c:/tmp/root' svn: Can't get shared lock on file 'c:/tmp/root/locks/db.lock': The process cann ot access the file because another process has locked a portion of the file. C:\tmp\work > ---------------------------------------------------------------------- Analysis of the TortoiseSVN equivalent of the above using a system call tracer seemed to indicate that the db.lock file was being opened, LockFile()d, opened again, and LockFile()d again without releasing the first lock. Is it a bug or a problem with my system? Thanks, jjs
Received on Thu Oct 21 23:11:02 2004