Main Page | Modules | Data Structures | File List | Data Fields | Globals

berkeley db filesystems

Subversion filesystems based on Berkeley DB. More...

Functions

svn_error_tsvn_fs_create_berkeley (svn_fs_t *fs, const char *path)
 Create a new, empty Subversion filesystem, stored in a Berkeley DB environment under path, a utf8-encoded path.

svn_error_tsvn_fs_open_berkeley (svn_fs_t *fs, const char *path)
 Make fs refer to the Berkeley DB-based Subversion filesystem at path.

const char * svn_fs_berkeley_path (svn_fs_t *fs, apr_pool_t *pool)
 Return the utf8-encoded path to fs's repository, allocated in pool.

svn_error_tsvn_fs_set_berkeley_errcall (svn_fs_t *fs, void(*handler)(const char *errpfx, char *msg))
 Register an error handling function for Berkeley DB error messages.

svn_error_tsvn_fs_delete_berkeley (const char *path, apr_pool_t *pool)
 Delete the Berkeley DB-based filesystem path.

svn_error_tsvn_fs_hotcopy_berkeley (const char *src_path, const char *dest_path, svn_boolean_t clean_logs, apr_pool_t *pool)
 Hot copy Subversion filesystem, stored in a Berkeley DB environment under src_path to dest_path.

svn_error_tsvn_fs_berkeley_recover (const char *path, apr_pool_t *pool)
 Perform any necessary non-catastrophic recovery on a Berkeley DB-based Subversion filesystem, stored in the environment path.

svn_error_tsvn_fs_berkeley_logfiles (apr_array_header_t **logfiles, const char *path, svn_boolean_t only_unused, apr_pool_t *pool)
 Set *logfiles to array of const char * log file names of Berkeley DB-based Subversion filesystem.


Detailed Description

Subversion filesystems based on Berkeley DB.

There are many possible ways to implement the Subversion filesystem interface. You could implement it directly using ordinary POSIX filesystem operations; you could build it using an SQL server as a back end; you could build it on RCS; and so on.

The functions on this page create filesystem objects that use Berkeley DB (http://www.sleepycat.com) to store their data. Berkeley DB supports transactions and recoverability, making it well-suited for Subversion.

A Berkeley DB ``environment'' is a Unix directory containing database files, log files, backing files for shared memory buffers, and so on --- everything necessary for a complex database application. Each Subversion filesystem lives in a single Berkeley DB environment.


Function Documentation

svn_error_t* svn_fs_berkeley_logfiles apr_array_header_t **  logfiles,
const char *  path,
svn_boolean_t  only_unused,
apr_pool_t *  pool
 

Set *logfiles to array of const char * log file names of Berkeley DB-based Subversion filesystem.

If only_unused is used is TRUE, *logfiles will contain only the names of Berkeley DB log files still in use by the filesystem. Otherwise, all log files (used and unused) are returned.

This function wraps the Berkeley DB 'log_archive' function called by the db_archive binary. Repository administrators may want to run this function periodically and delete the unused log files, as a way of reclaiming disk space.

const char* svn_fs_berkeley_path svn_fs_t fs,
apr_pool_t *  pool
 

Return the utf8-encoded path to fs's repository, allocated in pool.

Note: this is just what was passed to svn_fs_create_berkeley() or svn_fs_open_berkeley() -- might be absolute, might not.

svn_error_t* svn_fs_berkeley_recover const char *  path,
apr_pool_t *  pool
 

Perform any necessary non-catastrophic recovery on a Berkeley DB-based Subversion filesystem, stored in the environment path.

Do any necessary allocation within pool.

After an unexpected server exit, due to a server crash or a system crash, a Subversion filesystem based on Berkeley DB needs to run recovery procedures to bring the database back into a consistent state and release any locks that were held by the deceased process. The recovery procedures require exclusive access to the database --- while they execute, no other process or thread may access the database.

In a server with multiple worker processes, like Apache, if a worker process accessing the filesystem dies, you must stop the other worker processes, and run recovery. Then, the other worker processes can re-open the database and resume work.

If the server exited cleanly, there is no need to run recovery, but there is no harm in it, either, and it take very little time. So it's a fine idea to run recovery when the server process starts, before it begins handling any requests.

svn_error_t* svn_fs_create_berkeley svn_fs_t fs,
const char *  path
 

Create a new, empty Subversion filesystem, stored in a Berkeley DB environment under path, a utf8-encoded path.

Make fs refer to this new filesystem. fs provides the memory pool, warning function, etc. If path exists, it must be an empty directory.

svn_error_t* svn_fs_delete_berkeley const char *  path,
apr_pool_t *  pool
 

Delete the Berkeley DB-based filesystem path.

This deletes the database files, log files, shared memory segments, etc. path should refer to a file or directory created by svn_fs_create_berkeley.

svn_error_t* svn_fs_hotcopy_berkeley const char *  src_path,
const char *  dest_path,
svn_boolean_t  clean_logs,
apr_pool_t *  pool
 

Hot copy Subversion filesystem, stored in a Berkeley DB environment under src_path to dest_path.

If clean_logs is used is TRUE, delete copied, unused log files from source repository at src_path Using pool for any necessary memory allocations.

svn_error_t* svn_fs_open_berkeley svn_fs_t fs,
const char *  path
 

Make fs refer to the Berkeley DB-based Subversion filesystem at path.

path is utf8-encoded, and must refer to a file or directory created by svn_fs_create_berkeley.

Only one thread may operate on any given filesystem object at once. Two threads may access the same filesystem simultaneously only if they open separate filesystem objects.

NOTE: you probably don't want to use this directly, especially not if it's immediately preceded by a call to svn_fs_new(). Take a look at svn_repos_open() instead.

svn_error_t* svn_fs_set_berkeley_errcall svn_fs_t fs,
void(*  handler)(const char *errpfx, char *msg)
 

Register an error handling function for Berkeley DB error messages.

If a Berkeley DB error occurs, the filesystem will call handler with two strings: an error message prefix, which will be zero, and an error message. handler should print it out, log it somewhere, etc.

Since Berkeley DB's error messages are sometimes much more informative than the error codes the functions return, it's worth calling this function and providing some kind of error message handler.

This function calls DBENV->set_errcall, with handler as the db_errcall_fcn argument.


Generated on Mon Oct 18 17:33:15 2004 for Subversion by doxygen 1.3.5