2014-03-07 18:32 GMT+01:00 Chris Murphy <li...@colorremedies.com>: > On Mar 7, 2014, at 6:51 AM, Miloslav Trmač <m...@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. Mirek
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct