Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "FS2/Requirements" page has been changed by JulianFoad: http://wiki.apache.org/subversion/FS2/Requirements?action=diff&rev1=7&rev2=8 * svnsync: locks / rev-props * applicable to incremental backups * GUI updating of locks / rev-props + * Inhume "externals" - * Inhume "externals"; replace with: - * FS-level symlinks/"reparse points" - * cross-repository branch/merge (e.g., proper vendor branches) - * foreign-repository branch import (e.g., track git branch in svn) * ACLs * Mergeinfo / other unversioned data * Forward history tracing * Audit trail: rev-props / locks? / access control * Optimizable for (e.g.) size of data representation (Representation-agnistic API) * Abstracted from DB (SQL, distubuted, LevelDB, ...) + * Tags + * Branches ||<tablewidth="100%">'''"Versioned history" means ''' ||'''"Audit trail" means ''' || ||Reversible / time-safe (except for Obliterate which deliberately breaks this property) ||Not necessarily reversible / time-safe. It can be OK to just store a description of / metadata about each change that happened. || @@ -32, +31 @@ ==== svnsync: locks / rev-props ==== ==== GUI updating of locks / rev-props ==== ==== Inhume "externals" ==== + Replace "externals" with: + + * FS-level symlinks/"reparse points" + * cross-repository branch/merge (e.g., proper vendor branches) + * foreign-repository branch import (e.g., track git branch in svn) + + FS-level symlink: + + A node kind (in repository) alonside 'file' and 'dir', that: + + * appears as a named child of a directory (in the same way as 'file' and 'dir' nodes do) + * points to another node, by specifying 'node-id.branch-id[.txn-id?]' + * optionally specifies a revision number + + The client / WC: + + * doesn't see symlinks, but just sees a single versioned tree of files and dirs + * (therefore) recurses into them and behaves exactly as on a 'normal' WC + * knows when a node is "pinned" to a specified revision number and SHOULD block modifications and commits in such a subtree + + Compared with (same-repos) 'externals': + + * Ensures consistent behaviour of the client + * Allows the client to block modifications and commits in a "pinned" external + + TODO: + + * Implications for merging, especially w.r.t. cross-branch externals? + ==== ACLs ==== ==== Mergeinfo / other unversioned data ==== ==== Forward history tracing ==== ==== Audit trail: rev-props / locks? / access control ==== ==== Optimizable for (e.g.) size of data representation (Representation-agnistic API) ==== ==== Abstracted from DB (SQL, distubuted, LevelDB, ...) ==== + ==== Tags ==== + ==== Branches ====
