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)