[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Win32 Tests -- locks-test

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-04-04 21:13:48 CEST

On Mon, 4 Apr 2005, [UTF-8] Branko Ä^Libej wrote:

> Peter N. Lundblad wrote:
>
> >On Sun, 3 Apr 2005, D.J. Heap wrote:
> >
> >
> >
> >>Peter N. Lundblad wrote:
> >>[snip]
> >>
> >>
> >>>Well, the pool is cleared, eventually. We don't clear subpools on error.
> >>>I'm going to change this particular case (holding the write lock in FSFS),
> >>>since we don't know when the caller will clear the pool and locks should
> >>>be released when they're not needed anymore.
> >>>
> >>>
> >>>
> >>Sounds good to me. There are 3 or so other places where
> >>svn_fs_fs__get_write_lock is called and probably needs the same
> >>treatment on errors, I would think. I can post a patch for those later,
> >>if you don't get them.
> >>
> >>
> >>
> >I am replacing get_write_lock with a new with_write_lock function taking
> >another function/baton pair. That's happening in all places, including
> >commit.
> >
> >I timed out yesterday, but I'll finish it tonight. Hopefully before we
> >merge for 1.2, if that's actually happening today.
> >
> >
> I'd definitely want to see this fixed and tested on trunk *before* we
> branch 1.2. This is a major bug, and it makes no sense to start the 1.2
> soak period while it's in the code.
>
It's on trunk now. r13906. If someone could runtests on Windows, it'd be
great. (don't forget FS_TYPE=fsfs or whatever it is called in the windows
tests.:-) It passes on Linux (of course).

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 4 21:09:48 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.