Loading...
Searching...
No Matches
Filesystem nodes
Filesystem interaction subsystem

Filesystem Nodes and Node-Revisions. More...

## Typedefs

typedef enum svn_fs_node_relation_t | svn_fs_node_relation_t
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 }

## 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_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.

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

*/

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

Since
  New in 1.9.

## Typedef Documentation

## svn_fs_id_t

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.

## Enumeration Type Documentation

## svn_fs_node_relation_t

enum svn_fs_node_relation_t

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_fs_check_related()

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

References SVN_DEPRECATED.

## svn_fs_compare_ids()

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_parse_id()

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_fs_unparse_id()

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.