svn - 帮我论证为什么系统构建工具不应该自动执行 SVN checkin

Question

我正在尝试反对自动 checkin 版本控制。我的工作小组围绕 CFEngine 编写了一些系统构建工具，现在他们认为这些工具应该自动 checkin 诸如 SSH 主机 key 之类的东西。

现在，作为一名程序员，我最初的直觉 react 是除了人类之外，没有任何东西可以调用“svn up”和“svn ci”。在最近的一个案例中，一堆文件的 .rNNNN 合并版本破坏了工具，这就是开始讨论的原因。

现在，设计这些工具的人基本上已经承认他正在使用 SVN 来同步文件，并且他基本上可以用 NFS 装载替换所有这些。他甚至说他会将“svn diff”包装成“make diff”，因为这似乎比我们所有人都知道 SVN 的工作原理要好。

所以... 我请求这里的人群帮助我提出一个很好的论据，即当 Subversion 基本上用于同步时，没有 Makefiles、shell 脚本等包装 Subversion 命令不同机器上的文件。

到目前为止，这是我的 list :

1. 我们并没有真正对这些数据进行版本控制，所以它不应该放在 svn 中。
2. 我们已经说过它可以被 NFS 挂载取代，所以我们为什么不这样做。
3. 自家开发的工具现在包装 SVN，软件总是会有错误，因此我们的 SVN 修订现在遇到错误时会把修订搞得一团糟。

...请讨论/帮助我解决这个问题，或者告诉我您不同意的原因!

Answer 1

SVN 是用于在机器上同步文件的不错工具!如果我想让一堆机器拥有完全相同的文件版本，那么让它们处于颠覆状态并能够 check out 它们是天赐之物。是的，您可以使用 rsync 之类的工具或安装 NFS 来使它们保持最新，但至少颠覆允许您存储所有修订并在需要时回滚/转发。

不过我要说的是，让机器自动从主干更新可能不是一个好主意，因为这些文件可能会破坏您的系统，它们应该从标签更新。这样，您就可以 checkin 内容并维护修订历史记录，测试它们，然后应用一个标签，当文件更新时，该标签将在其他机器上同步文件。

我理解您对让这些工具自动提交的担忧，因为您可能觉得应该需要某种人工验证，但对我来说，消除人工交互可以消除流程中的人为错误，这正是我希望从此类系统中得到的结果.

当您在 svn 树上设置生产标签之前确认一切正常时，人的方面应该会出现。

总而言之，您的流程没有问题，但盲目地允许自动化流程将文件推送到可能破坏内容的环境则不行。