Version control

Flatconf 2.0 is designed in a way allowing (probably almost) any version control system to be embedded within the data tree.

Backup capability should be handled outside of Flatconf, and is rather a problem of the user interface than the standard.

Commands

VC-related commands are executed in the root of the data tree.

Required files in fc:/flatconf/*:

  • to see modifications:
    • fetch svn-like list of modified files in CURRENT - vc-modified [-r] [fc:path=/] [revision=RUNNING]
      • -r means recursive operation, e.g.
        M /dir/modifiedfile
        A /dir/list/addedelement
        D /dir/list/deletedelement
        
    • fetch previous values - vc-revert <fc:path> [revision=RUNNING]
      • if no previous value, then exit code = 1
  • to make use of modifications:
    • tag CURRENT as RUNNING - vc-tagrunning
      • ignore fc:paths listed in fc:/flatconf/vc-apply-failed
      • at the end delete fc:/flatconf/vc-apply-failed
    • tag CURRENT as SAVED - vc-tagsaved
  • optional:
    • if needed by the underlying VCS:
      • to run on adding files or directories - vc-add <fc:path>
      • to run on deleting files or directories - vc-del <fc:path>
      • to run before/after apply/save: vc-{before,after}-{apply,save}
    • support for "history" capability
      • fetch revision numbers - vc-revisions [fc:path=/]
      • fetch commit messages - vc-log [fc:path=/] <revision>

Commands should ignore fc:/flatconf. If $FC_ROOT is not present, they already are in the root of the data tree. Paths passed to VC system have already elnames translated into elids.

Revision names

  • !r10 - revision number 10
  • CURRENT - alias for the configuration being edited
  • RUNNING - alias for the most recently applied configuration
  • SAVED - alias for the most recently saved configuration (if no changes need to applied, then it's the same as RUNNING)