由于我们打包和部署软件的方式，我对所有文件复制承诺都使用“摘要”复制方法，所以我不能依靠mtime来更新文件。 出于各种原因，我没有在中央configuration服务器上采用客户端 – 服务器方法：相反，我们将整个configuration模块打包并部署到每个服务器，因此从cf-engine的angular度来看，源和目标在服务器上是本地的运行。
我使用这种方法时遇到的问题是，当源不同时，源将始终更新目标 – 这是我大部分时间需要的，通常是因为源已更新。
但是，像许多其他cfengine用户一样，我们正在运行一个操作环境，偶尔需要立即应用紧急修复 – 这意味着我们没有时间重新构build和重新部署configuration模块，并且通常会通过部署包含特定更改的tarball。 当然，如果cf-engine在5分钟之后出现并恢复更改，这是有问题的。
我们希望能够对我们的服务器进行小的，增量式的更改，直到下一个部署周期时新的源文件将被复制。 我们不考虑随机文件损坏或错误更改涉及足够的风险，以保证cfengine不断地将部署恢复到其源代码副本 – 部署紧急修复的能力，让他们保持这种方式，直到下一次部署将具有更大的价值和实用性。
所以，毕竟，我的问题是这样的：cf-engine能够检测文件不同时是否改变了源或目标，如果是这样，是他们使用“摘要”复制方法的一种方式，但只有如果源端改变了？ 我对其他想法和方法非常开放，因为对于整个configurationpipe理来说，我还是一个新手。
要知道是源还是目标发生了变化的唯一方法是使用时间戳，cfengine可以很好地完成。 也许你正在反思这个。 一般来说，我认为你要么让cfenginepipe理，要么你手工做。 寻找中间路线缺乏纪律，你很快就会犯错误。 我只会去自动化。
为什么不把你的configuration放在版本控制中，更新它而不是覆盖？ 而不是复制文件，
hg pull -u 要么
svn update
版本控制工具将为您处理本地更改，直到您有机会提交并将其推送回中央存储库。