版本控制的版本控制？

Question

在我的公司的上一个版本中，我一直在监督分支和合并，并且有很多次不得不修改我们的Subversion预提交挂钩，以强制在签入注释等方面执行不同的要求。每次编辑这些文件时，我都会有点紧张，因为(a)它们是实时生产系统的一部分，尽管只在内部使用(我们并不是一个庞大的组织)，以及(b)它们本身不受版本控制。

我很好奇人们在他们的版本控制基础设施上有什么样的失效安全机制。每日备份？"Meta“版本控制？我认为前者在这里是作为整个存储库备份的一部分。随着签入需求的复杂性增加，后者将非常有用……

Answer 1

性质-版本控制和任何其他基础设施代码也在版本控制之下，但我会使用一个独立于任何开发项目的项目。

我更喜欢一个可搜索的wiki或类似的知识库，而不是像VCS config这样的东西阻塞你的bug跟踪系统。

最重要的是，确保文档是最新的--根据我的经验，人们更擅长保持代码文档的最新，而不是管理员文档。这可能就是相关的个人。经常被忽视的一件事是，如果系统是根据标准Unix实践或类似的哲学配置的，这意味着OS/X或Windows程序员面对突然修复损坏的脚本时可能不熟悉的位置的大量知识。在不居高临下的情况下，确保关于位置和相互依赖的基本假设被记录下来。

Answer 2

您应该记录所有工具的所有“设置”配置，这些文档应该签入到版本控制中。对于带有允许注释的文本文件配置的工具，只需签入配置文件即可。但对于需要使用界面的工具，您应该有一个完整的文档，其中包含显示所选选项的对话框的图像。

但最重要的是，这些文档应该说明为什么要设置所选的值(当不采用默认值时)。

其次，作为备份，同样的文档应该包含在您的错误跟踪软件中的“如何设置版本控制软件？”虫子。( bug跟踪数据库位于不同的物理服务器上，对吗？)

第三，所有这些都应该在异地备份。我肯定有关于备份策略的问题。

Answer 3

对提交钩子和其他配置文件使用相同的版本控制存储库有什么错？这就是我过去负责项目配置管理时的处理方式。

您还应该备份svn存储库。这样，如果存储库本身损坏或服务器着火或其他情况，您可以恢复项目和svn控制文件。