Along with Subversion’s own datatypes, you will see many
references to datatypes that begin with apr_
—symbols from the Apache Portable Runtime
(APR) library. APR is Apache’s portability library, originally carved
out of its server code as an attempt to separate the OS-specific bits
from the OS-independent portions of the code. The result was a library
that provides a generic API for performing operations that differ
mildly—or wildly—from OS to OS.
While the Apache HTTP Server was obviously the first user of the APR
library, the Subversion developers immediately recognized the value of
using APR as well. This means that there is practically no OS-specific
code in Subversion itself. Also, it means that the Subversion client
compiles and runs anywhere that the Apache HTTP Server does. Currently,
this list includes all flavors of Unix, Win32, BeOS, OS/2, and Mac OS
X.
In addition to providing consistent implementations of system
calls that differ across operating systems,[54] APR gives Subversion immediate access to many custom
datatypes, such as dynamic arrays and hash tables. Subversion uses these
types extensively. But perhaps the most pervasive APR datatype, found in
nearly every Subversion API prototype, is the apr_pool_t
—the APR
memory pool. Subversion uses pools internally for all its memory
allocation needs (unless an external library requires a different memory
management mechanism for data passed through its API),[55] and while a person coding against the Subversion APIs is
not required to do the same, she is required to
provide pools to the API functions that need them. This means that users
of the Subversion API must also link against APR, must call apr_initialize()
to initialize the APR subsystem, and then must create and
manage pools for use with Subversion API calls, typically by using
svn_pool_create()
, svn_pool_clear()
, and svn_pool_destroy()
.