Filesystem nodes

Filesystem Nodes and Node-Revisions. More...

Typedefs
typedef enum svn_fs_node_relation_t	svn_fs_node_relation_t
	Defines the possible ways two arbitrary (root, path)-pairs may be related. More...
typedef struct svn_fs_id_t	svn_fs_id_t
	An object representing a node-revision id. More...

Enumerations
enum	svn_fs_node_relation_t {   svn_fs_node_unrelated = 0,   svn_fs_node_unchanged,   svn_fs_node_common_ancestor }
	Defines the possible ways two arbitrary (root, path)-pairs may be related. More...

Functions
int	svn_fs_compare_ids (const svn_fs_id_t *a, const svn_fs_id_t *b)
	Return -1, 0, or 1 if node revisions a and b are respectively unrelated, equivalent, or otherwise related (part of the same node). More...
svn_boolean_t	svn_fs_check_related (const svn_fs_id_t *id1, const svn_fs_id_t *id2)
	Return TRUE if node revisions id1 and id2 are related (part of the same node), else return FALSE. More...
svn_fs_id_t *	svn_fs_parse_id (const char *data, apr_size_t len, apr_pool_t *pool)
svn_string_t *	svn_fs_unparse_id (const svn_fs_id_t *id, apr_pool_t *pool)
	Return a Subversion string containing the unparsed form of the node revision id id. More...

Detailed Description

Filesystem Nodes and Node-Revisions.

In a Subversion filesystem, a `node' corresponds roughly to an `inode' in a Unix filesystem:

• A node is either a file or a directory.
• A node's contents change over time.
• When you change a node's contents, it's still the same node; it's just been changed. So a node's identity isn't bound to a specific set of contents.
• If you rename a node, it's still the same node, just under a different name. So a node's identity isn't bound to a particular filename.

A `node revision' refers to one particular version of a node's contents, that existed over a specific period of time (one or more repository revisions). Changing a node's contents always creates a new revision of that node, which is to say creates a new `node revision'. Once created, a node revision's contents never change.

When we create a node, its initial contents are the initial revision of the node. As users make changes to the node over time, we create new revisions of that same node. When a user commits a change that deletes a file from the filesystem, we don't delete the node, or any revision of it — those stick around to allow us to recreate prior revisions of the filesystem. Instead, we just remove the reference to the node from the directory.

Each node revision is a part of exactly one node, and appears only once in the history of that node. It is uniquely identified by a node revision id, svn_fs_id_t. Its node revision id also identifies which node it is a part of.

Note

: Often when we talk about `the node' within the context of a single revision (or transaction), we implicitly mean `the node as it appears in this revision (or transaction)', or in other words `the node revision'.

: Commonly, a node revision will have the same content as some other node revisions in the same node and in different nodes. The FS libraries allow different node revisions to share the same data without storing a separate copy of the data.

Typedef Documentation

typedef struct svn_fs_id_t svn_fs_id_t

An object representing a node-revision id.

Definition at line 966 of file svn_fs.h.

typedef enum svn_fs_node_relation_t svn_fs_node_relation_t

Defines the possible ways two arbitrary (root, path)-pairs may be related.

Since

New in 1.9.

Enumeration Type Documentation

enum svn_fs_node_relation_t

Defines the possible ways two arbitrary (root, path)-pairs may be related.

Since

New in 1.9.

Enumerator
svn_fs_node_unrelated	The (root, path)-pairs are not related, i.e. none of the other cases apply. If the roots refer to different svn_fs_t instances, then they are always considered unrelated - even if the underlying repository is the same.
svn_fs_node_unchanged	No changes have been made between the (root, path)-pairs, i.e. they have the same (relative) nodes in their sub-trees, corresponding sub- tree nodes have the same contents as well as properties and report the same "created-path" and "created-rev" data. This implies having a common ancestor. However, due to efficiency considerations, the FS implementation may report some combinations as merely having a common ancestor (svn_fs_node_common_ancestor) instead of actually being unchanged.
svn_fs_node_common_ancestor	The (root, path)-pairs have a common ancestor (which may be one of them) but there are changes between them, i.e. they don't fall into the svn_fs_node_unchanged category. Due to efficiency considerations, the FS implementation may falsely classify some combinations as merely having a common ancestor that are, in fact, unchanged (svn_fs_node_unchanged).

Definition at line 932 of file svn_fs.h.

Function Documentation

svn_boolean_t svn_fs_check_related	(	const svn_fs_id_t *	id1,
		const svn_fs_id_t *	id2
	)

Return TRUE if node revisions id1 and id2 are related (part of the same node), else return FALSE.

Note

Consider using the more expressive svn_fs_node_relation() instead.

See also

svn_fs_node_relation

int svn_fs_compare_ids	(	const svn_fs_id_t *	a,
		const svn_fs_id_t *	b
	)

Return -1, 0, or 1 if node revisions a and b are respectively unrelated, equivalent, or otherwise related (part of the same node).

Note

Consider using the more expressive svn_fs_node_relation() instead.

See also

svn_fs_node_relation

svn_fs_id_t* svn_fs_parse_id	(	const char *	data,
		apr_size_t	len,
		apr_pool_t *	pool
	)

Note

This function is not guaranteed to work with all filesystem types. There is currently no un-deprecated equivalent; contact the Subversion developers if you have a need for it.

Deprecated:

Provided for backward compatibility with the 1.0 API.

svn_string_t* svn_fs_unparse_id	(	const svn_fs_id_t *	id,
		apr_pool_t *	pool
	)

Return a Subversion string containing the unparsed form of the node revision id id.

Allocate the string containing the unparsed form in pool.