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

Branches

  • No labels