|
Size: 1765
Comment:
|
← Revision 8 as of 2012-10-26 15:39:21 ⇥
Size: 2689
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| * 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) |
* Inhume "externals" |
| Line 19: | Line 16: |
| * Tags * Branches |
|
| Line 33: | Line 32: |
| 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? |
|
| Line 39: | Line 67: |
| ==== Tags ==== ==== Branches ==== |
FS2: Use Cases and Reasons for Redesigning
Notes from Ben/Brane/Julian/Stefan on 2012-10-25
UCs & Reasons
- Obliterate
- svnsync: locks / rev-props
- applicable to incremental backups
- GUI updating of locks / rev-props
- Inhume "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
"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. |
Client-visible |
Admin-visible only |
History: for all time |
History: time span can be dynamically limited (FIFO) |
Details of the UCs & Reasons
Details with respect to the semantic properties of the whole-system design and of the file-system design.
Obliterate
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