Alien-SVN
view release on metacpan or search on metacpan
src/subversion/subversion/include/svn_fs.h view on Meta::CPAN
* a very desirable behavior and the default is, therefore, an empty
* namespace.
*
* If you want to be sure that your FS instance will actually read all
* requested data at least once, you need to specify a separate namespace
* for it. All repository verification code, for instance, should use
* some GUID here that is different each time you open an FS instance.
*
* @since New in 1.8.
*/
#define SVN_FS_CONFIG_FSFS_CACHE_NS "fsfs-cache-namespace"
/* Note to maintainers: if you add further SVN_FS_CONFIG_FSFS_CACHE_* knobs,
update fs_fs.c:verify_as_revision_before_current_plus_plus(). */
/* See also svn_fs_type(). */
/** @since New in 1.1. */
#define SVN_FS_CONFIG_FS_TYPE "fs-type"
/** @since New in 1.1. */
#define SVN_FS_TYPE_BDB "bdb"
/** @since New in 1.1. */
#define SVN_FS_TYPE_FSFS "fsfs"
/** Create repository format compatible with Subversion versions
* earlier than 1.4.
*
* @since New in 1.4.
*/
#define SVN_FS_CONFIG_PRE_1_4_COMPATIBLE "pre-1.4-compatible"
/** Create repository format compatible with Subversion versions
* earlier than 1.5.
*
* @since New in 1.5.
*/
#define SVN_FS_CONFIG_PRE_1_5_COMPATIBLE "pre-1.5-compatible"
/** Create repository format compatible with Subversion versions
* earlier than 1.6.
*
* @since New in 1.6.
*/
#define SVN_FS_CONFIG_PRE_1_6_COMPATIBLE "pre-1.6-compatible"
/** Create repository format compatible with Subversion versions
* earlier than 1.8.
*
* @since New in 1.8.
*/
#define SVN_FS_CONFIG_PRE_1_8_COMPATIBLE "pre-1.8-compatible"
/** @} */
/**
* Callers should invoke this function to initialize global state in
* the FS library before creating FS objects. If this function is
* invoked, no FS objects may be created in another thread at the same
* time as this invocation, and the provided @a pool must last longer
* than any FS object created subsequently.
*
* If this function is not called, the FS library will make a best
* effort to bootstrap a mutex for protecting data common to FS
* objects; however, there is a small window of failure. Also, a
* small amount of data will be leaked if the Subversion FS library is
* dynamically unloaded, and using the bdb FS can potentially segfault
* or invoke other undefined behavior if this function is not called
* with an appropriate pool (such as the pool the module was loaded into)
* when loaded dynamically.
*
* If this function is called multiple times before the pool passed to
* the first call is destroyed or cleared, the later calls will have
* no effect.
*
* @since New in 1.2.
*/
svn_error_t *
svn_fs_initialize(apr_pool_t *pool);
/** The type of a warning callback function. @a baton is the value specified
* in the call to svn_fs_set_warning_func(); the filesystem passes it through
* to the callback. @a err contains the warning message.
*
* The callback function should not clear the error that is passed to it;
* its caller should do that.
*/
typedef void (*svn_fs_warning_callback_t)(void *baton, svn_error_t *err);
/** Provide a callback function, @a warning, that @a fs should use to
* report (non-fatal) errors. To print an error, the filesystem will call
* @a warning, passing it @a warning_baton and the error.
*
* By default, this is set to a function that will crash the process.
* Dumping to @c stderr or <tt>/dev/tty</tt> is not acceptable default
* behavior for server processes, since those may both be equivalent to
* <tt>/dev/null</tt>.
*/
void
svn_fs_set_warning_func(svn_fs_t *fs,
svn_fs_warning_callback_t warning,
void *warning_baton);
/**
* Create a new, empty Subversion filesystem, stored in the directory
* @a path, and return a pointer to it in @a *fs_p. @a path must not
* currently exist, but its parent must exist. If @a fs_config is not
* @c NULL, the options it contains modify the behavior of the
* filesystem. The interpretation of @a fs_config is specific to the
* filesystem back-end. The new filesystem may be closed by
* destroying @a pool.
*
* @note The lifetime of @a fs_config must not be shorter than @a
* pool's. It's a good idea to allocate @a fs_config from @a pool or
* one of its ancestors.
*
* If @a fs_config contains a value for #SVN_FS_CONFIG_FS_TYPE, that
* value determines the filesystem type for the new filesystem.
* Currently defined values are:
src/subversion/subversion/include/svn_fs.h view on Meta::CPAN
* client disappeared before the change was complete), you can call
* svn_fs_abort_txn(), to cancel the entire transaction; this
* leaves the filesystem unchanged.
*
* The only way to change the contents of files or directories, or
* their properties, is by making a transaction and creating a new
* revision, as described above. Once a revision has been committed, it
* never changes again; the filesystem interface provides no means to
* go back and edit the contents of an old revision. Once history has
* been recorded, it is set in stone. Clients depend on this property
* to do updates and commits reliably; proxies depend on this property
* to cache changes accurately; and so on.
*
* There are two kinds of nodes in the filesystem: mutable, and
* immutable. Revisions in the filesystem consist entirely of
* immutable nodes, whose contents never change. A transaction in
* progress, which the user is still constructing, uses mutable nodes
* for those nodes which have been changed so far, and refers to
* immutable nodes from existing revisions for portions of the tree
* which haven't been changed yet in that transaction.
*
* Immutable nodes, as part of revisions, never refer to mutable
* nodes, which are part of uncommitted transactions. Mutable nodes
* may refer to immutable nodes, or other mutable nodes.
*
* Note that the terms "immutable" and "mutable" describe whether or
* not the nodes have been changed as part of a transaction --- not
* the permissions on the nodes they refer to. Even if you aren't
* authorized to modify the filesystem's root directory, you might be
* authorized to change some descendant of the root; doing so would
* create a new mutable copy of the root directory. Mutability refers
* to the role of the node: part of an existing revision, or part of a
* new one. This is independent of your authorization to make changes
* to a given node.
*
* Transactions are actually persistent objects, stored in the
* database. You can open a filesystem, begin a transaction, and
* close the filesystem, and then a separate process could open the
* filesystem, pick up the same transaction, and continue work on it.
* When a transaction is successfully committed, it is removed from
* the database.
*
* Every transaction is assigned a name. You can open a transaction
* by name, and resume work on it, or find out the name of a
* transaction you already have open. You can also list all the
* transactions currently present in the database.
*
* You may assign properties to transactions; these are name/value
* pairs. When you commit a transaction, all of its properties become
* unversioned revision properties of the new revision. (There is one
* exception: the svn:date property will be automatically set on new
* transactions to the date that the transaction was created, and will
* be overwritten when the transaction is committed by the current
* time; changes to a transaction's svn:date property will not affect
* its committed value.)
*
* Transaction names are guaranteed to contain only letters (upper-
* and lower-case), digits, `-', and `.', from the ASCII character
* set.
*
* The Subversion filesystem will make a best effort to not reuse
* transaction names. The Berkeley DB backend generates transaction
* names using a sequence, or a counter, which is stored in the BDB
* database. Each new transaction increments the counter. The
* current value of the counter is not serialized into a filesystem
* dump file, so dumping and restoring the repository will reset the
* sequence and reuse transaction names. The FSFS backend generates a
* transaction name using the hostname, process ID and current time in
* microseconds since 00:00:00 January 1, 1970 UTC. So it is
* extremely unlikely that a transaction name will be reused.
*
* @defgroup svn_fs_txns Filesystem transactions
* @{
*/
/** The type of a Subversion transaction object. */
typedef struct svn_fs_txn_t svn_fs_txn_t;
/** @defgroup svn_fs_begin_txn2_flags Bitmask flags for svn_fs_begin_txn2()
* @since New in 1.2.
* @{ */
/** Do on-the-fly out-of-dateness checks. That is, an fs routine may
* throw error if a caller tries to edit an out-of-date item in the
* transaction.
*
* @warning ### Not yet implemented.
*/
#define SVN_FS_TXN_CHECK_OOD 0x00001
/** Do on-the-fly lock checks. That is, an fs routine may throw error
* if a caller tries to edit a locked item without having rights to the lock.
*/
#define SVN_FS_TXN_CHECK_LOCKS 0x00002
/** @} */
/**
* Begin a new transaction on the filesystem @a fs, based on existing
* revision @a rev. Set @a *txn_p to a pointer to the new transaction.
* When committed, this transaction will create a new revision.
*
* Allocate the new transaction in @a pool; when @a pool is freed, the new
* transaction will be closed (neither committed nor aborted).
*
* @a flags determines transaction enforcement behaviors, and is composed
* from the constants SVN_FS_TXN_* (#SVN_FS_TXN_CHECK_OOD etc.).
*
* @note If you're building a txn for committing, you probably
* don't want to call this directly. Instead, call
* svn_repos_fs_begin_txn_for_commit(), which honors the
* repository's hook configurations.
*
* @since New in 1.2.
*/
svn_error_t *
svn_fs_begin_txn2(svn_fs_txn_t **txn_p,
svn_fs_t *fs,
svn_revnum_t rev,
apr_uint32_t flags,
src/subversion/subversion/include/svn_fs.h view on Meta::CPAN
apr_pool_t *pool);
/**
* Same as svn_fs_file_checksum(), only always put the MD5 checksum of file
* @a path into @a digest, which should point to @c APR_MD5_DIGESTSIZE bytes
* of storage. If the checksum doesn't exist, put all 0's into @a digest.
*
* @deprecated Provided for backward compatibility with the 1.5 API.
*/
SVN_DEPRECATED
svn_error_t *
svn_fs_file_md5_checksum(unsigned char digest[],
svn_fs_root_t *root,
const char *path,
apr_pool_t *pool);
/** Set @a *contents to a readable generic stream that will yield the
* contents of the file @a path in @a root. Allocate the stream in
* @a pool. You can only use @a *contents for as long as the underlying
* filesystem is open. If @a path is not a file, return
* #SVN_ERR_FS_NOT_FILE.
*
* If @a root is the root of a transaction, it is possible that the
* contents of the file @a path will change between calls to
* svn_fs_file_contents(). In that case, the result of reading from
* @a *contents is undefined.
*
* ### @todo kff: I am worried about lifetime issues with this pool vs
* the trail created farther down the call stack. Trace this function
* to investigate...
*/
svn_error_t *
svn_fs_file_contents(svn_stream_t **contents,
svn_fs_root_t *root,
const char *path,
apr_pool_t *pool);
/**
* Callback function type used with svn_fs_try_process_file_contents()
* that delivers the immutable, non-NULL @a contents of @a len bytes.
* @a baton is an implementation-specific closure.
*
* Use @a scratch_pool for allocations.
*
* @since New in 1.8.
*/
typedef svn_error_t *
(*svn_fs_process_contents_func_t)(const unsigned char *contents,
apr_size_t len,
void *baton,
apr_pool_t *scratch_pool);
/** Efficiently deliver the contents of the file @a path in @a root
* via @a processor (with @a baton), setting @a *success to @c TRUE
* upon doing so. Use @a pool for allocations.
*
* This function is intended to support zero copy data processing. It may
* not be implemented for all data backends or not applicable for certain
* content. In that case, @a *success will always be @c FALSE. Also, this
* is a best-effort function which means that there is no guarantee that
* @a processor gets called at all for some content.
*
* @note @a processor is expected to be relatively short function with
* at most O(content size) runtime.
*
* @since New in 1.8.
*/
svn_error_t *
svn_fs_try_process_file_contents(svn_boolean_t *success,
svn_fs_root_t *root,
const char *path,
svn_fs_process_contents_func_t processor,
void* baton,
apr_pool_t *pool);
/** Create a new file named @a path in @a root. The file's initial contents
* are the empty string, and it has no properties. @a root must be the
* root of a transaction, not a revision.
*
* Do any necessary temporary allocation in @a pool.
*/
svn_error_t *
svn_fs_make_file(svn_fs_root_t *root,
const char *path,
apr_pool_t *pool);
/** Apply a text delta to the file @a path in @a root. @a root must be the
* root of a transaction, not a revision.
*
* Set @a *contents_p to a function ready to receive text delta windows
* describing how to change the file's contents, relative to its
* current contents. Set @a *contents_baton_p to a baton to pass to
* @a *contents_p.
*
* If @a path does not exist in @a root, return an error. (You cannot use
* this routine to create new files; use svn_fs_make_file() to create
* an empty file first.)
*
* @a base_checksum is the hex MD5 digest for the base text against
* which the delta is to be applied; it is ignored if NULL, and may be
* ignored even if not NULL. If it is not ignored, it must match the
* checksum of the base text against which svndiff data is being
* applied; if not, svn_fs_apply_textdelta() or the @a *contents_p call
* which detects the mismatch will return the error
* #SVN_ERR_CHECKSUM_MISMATCH (if there is no base text, there may
* still be an error if @a base_checksum is neither NULL nor the
* checksum of the empty string).
*
* @a result_checksum is the hex MD5 digest for the fulltext that
* results from this delta application. It is ignored if NULL, but if
* not NULL, it must match the checksum of the result; if it does not,
* then the @a *contents_p call which detects the mismatch will return
* the error #SVN_ERR_CHECKSUM_MISMATCH.
*
* The caller must send all delta windows including the terminating
* NULL window to @a *contents_p before making further changes to the
* transaction.
*
* Do temporary allocation in @a pool.
( run in 0.923 second using v1.01-cache-2.11-cpan-524268b4103 )