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

Re: Is mod_dav_svn safe for use in a threaded MPM?

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-04-05 19:00:09 CEST

On Thu, Apr 05, 2007 at 09:32:42AM -0700, Eric Gillespie wrote:
> Malcolm Rowe <malcolm-svn-dev@farside.org.uk> writes:
>
> > mod_dav_svn maintains an activity database - a mapping of DAV-generated
> > identifiers to Subversion transaction id's. It implements this using
> > APR-util's dbm implementation, which may be BDB, gdbm, or one of several
> > other dbm-a-like implementations.
>
> This is a simple key-value lookup. It needs nothing fancy at
> all. Why not do the simple, obvious thing and have filenames as
> keys and file contents as values? I already have a patch to do
> just this.
>

Right, that sounds like an excellent way to handle this - removing the
dependency on the default APR dbm implementation, and making it work in
threaded MPMs in one go :-) You don't even have to worry about NFS's
odd O_EXCL behaviour, since you're only associating a specified DAV
activity/transaction id pair.

> I haven't thought about compatibility, but what about calling the
> new database 'activities.d' instead of 'activities'?

We'd either need to create the new directory on-demand (realistically,
we'd do it whenever we needed to write a new association) or alternatively
bump the repository format number and retain the backward-compatibility
code.

Theoretically, we can't do the first because of our compatibility rules,
but as we don't really support long-lived transactions, it might be
acceptable. (The other problem would come from people using multiple
mod_dav_svn servers to a single backend, and mixing versions, but that's
what started this problem off...).

Regards,
Malcolm

  • application/pgp-signature attachment: stored
Received on Thu Apr 5 19:01:25 2007

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.