如何论证为什么系统构建工具不应该自动执行 SVN 签入
我正在尝试反对自动签入版本控制。 我的工作小组已经围绕 CFEngine 编写了一些系统构建工具，现在他们认为这些工具应该自动执行诸如 SSH 主机密钥之类的检查。
现在，作为一名程序员，我最初的直觉反应是除了人类之外没有任何东西应该调用“svn up”和“svn ci”。 在最近的一个案例中，.rNNNN 合并了一堆文件的版本破坏了工具，这就是本次讨论的开始。
现在，设计工具的人基本上承认他使用 SVN 来同步文件，并且他基本上可以用 NFS 安装来替换所有这些。 他甚至说他会将“svn diff”包装成“make diff”，因为这似乎比我们所有人都知道 SVN 的工作原理更好。
所以... 我问的是，当 Subversion 基本上用于同步不同计算机上的文件时，如何才能提出一个很好的论据，证明没有 Makefile、shell 脚本等来包装 Subversion 命令。
到目前为止，这是我的列表：
- 我们并没有真正对这些数据进行版本控制，因此它不应该进入 svn。
- 我们已经说过它可以被 NFS 安装取代，所以我们为什么不这样做呢。
- 本土工具现在正在包装 SVN，而软件总是会出现错误，因此当我们遇到错误时，我们的 SVN 修订版本现在会变得混乱。
我该如何解释这种情况？
I'm trying to make a case against automated checkins to version control. My group at work has written some system build tools around CFEngine, and now they think these tools should automatically do checkins of things like SSH host keys.
Now, as a programmer, my initial gut reaction is that nothing should be calling "svn up" and "svn ci" aside from a human. In a recent case, the .rNNNN merged versions of a bunch of files broke the tools, which is what started this discussion.
Now, the guy designing the tools has basically admitted he's using SVN in order to sync files around, and that he could basically replace all this with an NFS mount. He even said he would wrap "svn diff" into "make diff" because it seemed better than all of us knowing how SVN works.
So... I'm asking how I can make a good argument for NOT having Makefiles, shell scripts, etc, wrap Subversion commands, when Subversion is basically being used to synchronize files on different machines.
Here's my list, so far:
- We aren't really versioning this data, so it shouldn't go in svn.
- We've said it could be replaced by an NFS mount, so why don't we do that.
- Homegrown tools are now wrapping SVN, and software is always going to have bugs, therefore our SVN revisions are now going to have messes made of a revision when we encounter bugs.
How can I make this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
SVN 是一个在机器上同步文件的好工具！ 如果我希望一堆机器拥有完全相同的文件版本，那么将它们放入 subversion 并能够检查它们就是天赐之物。 是的，您可以使用 rsync 等工具或使用 NFS 挂载来使它们保持最新状态，但至少 Subversion 允许您存储所有修订并在需要时回滚/前进。
我要说的一件事是，让机器从主干自动更新可能是一个坏主意，当这些文件可能会破坏您的系统时，它们应该从标签进行更新。 这样，您可以签入内容并维护修订历史记录，测试它们，然后应用一个标签，在文件更新时同步其他计算机上的文件。
我理解您对让这些工具自动提交的担忧，因为您可能觉得应该需要某种人工验证，但对我来说，消除人工交互可以消除流程中的人为错误，这正是我想要从此类系统中得到的。
当您在 svn 树上设置生产标签之前确认一切正常时，就应该考虑到人的因素。
总之，您的流程很好，盲目地允许自动化流程将文件推送到可能破坏事物的环境中。
SVN isn't a bad tool to use to synchronise files on machines! If I want a bunch of machines to have the exact same version of file then having them in subversion and being able to check them out is a godsend. Yeah, you could use tools such as rsync or have NFS mounts to keep them up-to-date but at least subversion allows you to store all revisions and roll-back/forward when you want.
One thing I will say though, is having machines automatically update from the trunk is probably a bad idea when those files could break your system, they should update from a tag. That way, you can check things in and maintain revision history TEST them and then apply a tag that will sync the files on other machines when they update.
I understand your concerns for having these tools auto-commit because you perhaps feel there should be some sort of human validation required but for me, removing human interaction removes human error from the process which is what I want from this type of system.
The human aspect should come into things when you are confirming all is working before setting a production tag on the svn tree.
In summary, your process is fine, blindly allowing an automated process to push files to an environment where they could break things is not.
实际上SVN比NFS更好。 至少它提供了一个原子一致的全局视图（即，您不会同步文件的半提交视图）。 我反对开发自动化提交，因为它不允许同行评审过程，但对于管理工作来说 SVN 非常有用。 我的2c。
Actually SVN is better than NFS. At least it provides an atomically consistent global view (ie. you won't sync a half committed view of the files). I would argue against development automated commits because it does not allow for a peer review process, but for administration jobs SVN is quite useful. My 2c.
这是旧鞋v是玻璃瓶的另一个例子 辩论。
在这种情况下，NFS 挂载可能是正确的选择，我们的夜间构建会提交版本控制更改，仅此而已。
您的 SVN 存储库用于帮助版本控制和构建代码。 如果你正在做的事情以任何方式危害到这一点，那就不要这样做。
如果 SVN 绝对是最好的方法，那么创建一个单独的存储库并使用它，不要管关键存储库。
It's another example of the Old shoe v's the glass bottle debate.
In this instance the NFS mount may be the way to go, our nightly build commits versioning changes, and thats it.
Your SVN repository is what you use to help version and build your code. If what you're doing jeopardises this in any way, THEN DON'T DO IT.
If SVN is absolutely, positively the best way to do this, then create a separate repository and use that, leave the critical repository alone.
只有人类应该做出承诺，但我认为没有理由禁止自动签出和更新。 唯一的事情是确保人类将工作和测试的代码提交到进行自动更新的地方。
NFS 有点酷，但如果 NFS 服务器坏了，你就有麻烦了。 您可以尝试使用 GlusterFS 之类的东西来拥有多个数据副本（但不要尝试
ls一个 glusterfs 目录，因为它的时间复杂度为 O(number of files) ）。Neil Trodden在该线程中的标签上发表了精彩的评论，我想它可以解决您的问题。Only humans should commit, but I see no reason of forbidding automated checkouts and updates. The only thing is to ensure humans commit the working and tested code to the place from where the automated updates are being made.
NFS is kinda cool but if the NFS server breaks, You are in trouble. You can try using something like GlusterFS to have multiple copies of data (but don't try to
lsa glusterfs directory, as it's O(number of files) ).Neil Troddenposted an excellent remark on tags in this thread, it'd solve Your problem I suppose.