目前我们正在使用Puppet（在SVN中有清单和相关文件）来pipe理我们的* nix主机的configuration。 不过，我碰到了一个令人困惑的问题。
我们的许多主机都具有特定于主机的脚本 – cron作业，数据挖掘脚本，dynamic生成configuration文件的脚本等。我正在寻找一种方法来pipe理这些脚本，特别是对它们进行版本化，并允许一个相对简单的恢复解决schemeif主机重build，而不改变现有的布局。
我似乎无法find对我们的环境“有效”的解决scheme。
我想最简单的方法来解释我在找什么是我想要但不存在：
有什么build议么？
这里真正的问题不在于SCM系统，而在于您无法控制用户在生产环境中进行不受控制的更改。 除非让用户检查更改，否则configuration控制并不是真正的正确方法。 这听起来像你真的需要一个好的备份解决scheme，你可以用它来快速恢复工作映像。
如果你想能够用puppet恢复“configuration”，而不是传统的备份解决scheme（你应该有的话），你可能想看看使用Jordan Sissel的fpm http://www.semicomplete.com/blog /geekery/fpm.html 。 fpm实际上是用来生成软件包（rpm，deb等），但是它可以输出一个给定文件列表的puppet模块。 你可以在每台主机上运行一个cronjob，并用该主机脚本生成一个puppet模块，并将其检入到svn / git / etc中。
FSVS是Unix的Subversion客户端，允许你使用文件系统的任何部分作为工作副本。 它将SVN数据存储在/ var下，所以它不会在.svn子文件夹中散布你的目录。 重要的是，它透明地将Unix文件元数据存储在SVN属性中。
你用它很像你会在命令行上使用svn：
cd /home/mydir fsvs urls svn+ssh://yoursvnrepohost/var/svn/yourrepo/home/mydir fsvs exclude ./tmp fsvs commit -m 'initial commit' （……）
fsvs log fsvs diff thatconfigfile
您可以使用任何SVN工具浏览生成的SVN回购。
我还build议添加一个每日cronjob在/做一个自动提交。
你还必须排除很多文件，caching，临时目录等等，否则你会用垃圾填满你的仓库。
我build议直接在服务器上更新版本控制库。 我将大部分生产configuration保留在基础架构存储库上。
这听起来像是你试图过度devise解决scheme。 不要使用符号链接，让他们在任意位置使用SVN。
虽然有SCM可以存储链接，但我不知道任何SCM系统都以这种方式处理链接。 他们也不应该恕我直言！ 如果你想同时在两个不同的分支上工作，并检出两份，每个分支一份？ （这在我编程项目的经验中是相当普遍的。）如果每个指向磁盘上其他地方的相同文件，它们就会造成混乱。
SCM通常会留下属于他们的目录。 这允许多个签出的回购站并排地生活而不受干扰，并且使SCMpipe理的文件和非SCMpipe理的文件之间的界限变得清晰。
我将build立一个围绕复制和显式部署操作的解决scheme，而不是链接。 为了处理您的情况，我会在脚本的部署位置和SCMpipe理的源目录（我将称之为“repo”）之间编写同步脚本，以便您可以吸收脚本的原位编辑进入回购。 我也将使用一个简单的运行部署脚本（基于Puppet的），从回购站复制到目标位置进行testing。
虽然我同意重新训练开发人员在Subversion中进行编辑可能会更好，但是您可以在不付出太多努力的情况下对其进行合理的修改。
我首先创build一个目录或存储库（取决于你的环境中最有意义的东西），每个主机都有一个子目录，你希望这样pipe理。 在这些目录下面，以结构化的方式放置你想要pipe理的文件。 就我个人而言，我会这样做：
per_host_confs /
主机1 /
等等/
cron.d /
FOO
logrotate.d /
酒吧
VAR /
...
然后添加一个cronjob（或者添加一个puppet规则），运行一个脚本来检查当前主机目录的主干（$ hostnamevariables在你的木偶配方中会有帮助）到一些临时目录，find一个目录并将相关文件复制到工作副本中，然后提交。
重新部署它的puppet规则可以做类似的事情，并使用创build或检查修改时间来确定何时将工作副本/ repo中的文件推送到本地磁盘上。
你可以用另一种方式来做符号链接吗？ 有一个由svnpipe理的目录（比如/usr/local/scripts/ ），然后将所有脚本复制到该目录（或子目录）中，并在旧位置中放置一个符号链接。 然后，每当有人编辑文件，他们实际上编辑svn目录中的文件。
如果sym链接不能这样工作，那么你可以使用硬链接。
一旦你完成了，你可以尝试和鼓励你的员工在新的地方编辑文件，并逐渐标准化新的目录结构。 作为一个后盾，你可以有一个cron工作，每天晚上做一个检查，并发邮件给你，让你知道谁不使用新系统，所以你可以友好的提醒相关人员。