2014-03-07 18:32 GMT+01:00 Chris Murphy <lists@colorremedies.com>:
On Mar 7, 2014, at 6:51 AM, Miloslav Trmač <mitr@volny.cz> wrote:
  • For configuration: What we really want is a VCS, dealing with changesets, documenting who has changed what, when and why.  Snapshots are a really poor VCS.
Obviously we don't have all that technology that we "really want", or at least not in a way that is ready to deploy, but we kind of have snapshots.  Let's just not think that snapshots are "right".
To do VCS correctly requires application opt-in, and an API to manage it.

Yes, ideally; but actually it would still be useful for every fedora-server-role-manage subcommand to:
1) check if /etc has changed at all since the last committed state; if so, (git commit -m 'Unknown unmanaged changes between $timestamp and $timestamp'), and optionally alert an admin
2) perform the primarily role of the subcommand as intended
3) (git commit -m 'performed $command for $user'), unless the admin has explicitly disabled autocommit.  (Asking for a rationale in the change log should be an option but probably not default.)

We could then expand this from fedora-server-role-manage to other tools.
How do I get revision control with file formats that don't support it like RTF, txt, PNG, TIFF, etc?

The way we already do this with git: git gives you full revision control, and we lack the tools show the differences in a nice UI or to do a reasonable three-way merge.  But note that revision control is still quite useful in this scenario: it gives you the ability to go back in time, to track responsibility and rationale for changes, and if you really need to, you can compare the content manually.