Subversion
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
Typedefs | Enumerations | Functions
Filesystem nodes
Filesystem interaction subsystem

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.
 
typedef struct svn_fs_id_t svn_fs_id_t
 An object representing a node-revision id.
 

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).
 
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.
 
svn_fs_id_tsvn_fs_parse_id (const char *data, apr_size_t len, apr_pool_t *pool)
 
svn_string_tsvn_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.
 

Detailed Description

Filesystem Nodes and Node-Revisions.

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

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 930 of file svn_fs.h.

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

Since
New in 1.9.

Enumeration Type Documentation

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 896 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.