Greg Hudson <ghudson <at> MIT.EDU> writes:
>
> On Sat, 2004-10-23 at 16:15, John J Smith wrote:
> > 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?
>
> Well, the kind of lock we're getting on that file is a shared lock, so
> it should be okay to get it twice. So, I'll go with "a problem with
> your system." (Though perhaps with win98 in general, and not just with
> your system in particular. Do other people have experience with trying
> FSFS under win98?)
>
> In the long run, I'd like FSFS to work even on systems which aren't 100%
> correct, which means not grabbing the recovery read lock. That lock
> isn't really necessary for FSFS repositories anyway, at least as long as
> recovery isn't doing anything.
>
> I don't know if I can promise a fix in 1.1.2, but maybe. (If you are in
> a position to build the svn code yourself, I could supply a patch which
> would break BDB functionality--not a loss on win98--but eliminate your
> locking problem.)
>
I've just picked up on this thread - better late than never. I have the same
problem with checkouts under Windows ME. I'm currently on SVN 1.1.4 and
Tortoise SVN 1.1.5. Both behave the same (as did 1.1.3).
Any chance of providing a workaround or a proper fix? I'd love to dump CVS and
migrate to SVN but until I can get around this problem, it's not practical.
Thanks,
Steve Beet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 15 16:45:38 2005