Yves Dorfsman: >> The sad part is that you consider this unorthodox. >> RCS, mercurial, git, etc... are so cheap to use that there is absolutely no >> reason not to use them for NIS, DNS, ldif files etc...
Jesse Becker: > To take it a step further: any machine should have its configuration > management tool rules/promises/recipes under VC. I also agree that configuration files, rules/promises/recipes or other directory lookup files aren't really "unorthodox" uses of VC. Although I would definitely lean toward rules/promises/recipes over importing /etc into local or one or more central repositories. I can't imagine /etc repositories scaling very well to thousands of machines...whereas a unified collection of rules/promises/recipes under a single VC repository certainly would scale with little issue...at least from the VC side of things. Something else I've done in the past which I don't necessarily consider unorthodox: putting websites under VC...particularly "canned" web services such as RT, Wordpress, Gallery, etc. Especially if the source is checked out from the repository instead of deploying it by tarball. If I use a cloned git repository as an example, then updating the underlying website code could be as straight forward as re-basing your local configuration commits on top of the new HEAD of the remote branch. (With subversion I think the equivalent would be 'svn update' to update the underlying revision to the latest one.) I guess another example of an unorthodox use would be, as Adam Compton suggested, using a centralized VC repository to synchronize/share files between multiple hosts. A similar idea I've been tossing around for an environment is to maintain a site-wide Perl library under VC. This would be a mix of CPAN and in-house modules that aren't included in the core nor in the base install from the vendor. My reasoning is that CPAN (or CPANPlus, though I haven't extensively used it yet) does a pretty good job of resolving it's dependencies, but it doesn't scale well for keeping multiple hosts in sync. At the same time, building rpms for Perl modules, perhaps via cpan2rpm, is suboptimal because of the dependencies that get left out. Not only that, but the rpms that are deployed are then disconnected from any documentation on _why_ they were deployed. Obviously, the Perl library would then be kept in sync across multiple hosts by "checking out" or "cloning" the library on them at regular intervals. --Aaron _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
