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

Re: HP-UX failures

From: <cmpilato_at_collab.net>
Date: 2002-04-19 07:10:53 CEST

=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <branko.cibej@hermes.si> writes:

> Turns out this is a faq:
>
> =====================
> *An ENOMEM error is returned from DB_ENV->open
> <http://www.sleepycat.com/docs/api_c/env_open.html> or DB_ENV->remove
> <http://www.sleepycat.com/docs/api_c/env_remove.html> .*
>
> Due to the constraints of the PA-RISC memory architecture, HP-UX does
> not allow a process to map a file into its address space multiple times.
> For this reason, each Berkeley DB environment may be opened only once by
> a process on HP-UX; that is, calls to DB_ENV->open
> <http://www.sleepycat.com/docs/api_c/env_open.html> will fail if the
> specified Berkeley DB environment has been opened and not subsequently
> closed.
>
> =====================
>
> Opening an environment more than once is exactly what we do in
> svn_ral_local__split_URL. We either have to get rid of that function,
> keep a list of currently open DB's around, or not work on HP-UX.
>
> (Actually, since we don't support cross-repository copies, we knoy have
> to remember the URL of the laready-open repo. Which makes sense, because
> then we can just do a strncmp on the URL next time we try to open it,
> instead of jumping through hoops the way we do now.)

I think that once we have storage of canonical repos URLs in our
entries files (soon to occur), svn_ra_local__split_URL() won't be
used quite as much. It still must exist, as there are times (import)
when there are no entries files to read.

Of course, we *could* just change any subcommands that today use
REPOS_URLs to instead use both a REPOS_URL (that is, a canonical repos
URL, like http://svn.collab.net/repos/svn) and a REPOS_PATH (like
trunk). I certainly *hope* we don't do such a thing, though.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 19 07:14:21 2002

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.