我在公司的最后一个版本中一直在监督分支和合并，并且多次不得不修改我们的 Subversion 预提交挂钩以对签入 cmets 等实施不同的要求。每次编辑这些文件时我都有些紧张，因为 (a) 它们是现场制作系统的一部分，尽管只在内部使用（而且我们不是一个庞大的组织），并且 (b) 它们不是受版本控制。
我很好奇人们在他们的版本控制基础架构上设置了什么样的故障保护措施。每日备份？ “元”版本控制？我想前者作为整个存储库备份的一部分在这里就位。随着签入要求的复杂性增加，后者将很有用......
【问题讨论】：
标签： version-control
如果您有执行此操作的构建脚本（例如 Nant），那么您可以签入这些脚本。
【讨论】：
您应该记录所有工具的所有“设置”配置，并且这些文档应该检查到版本控制中。对于具有允许 cmets 的文本文件配置的工具，您只需签入配置文件即可。但是对于需要使用该界面的工具，您应该有一个完整的文档，其中包含显示选择的对话框的图像。
但最重要的是，这些文档应该说明为什么您设置了选择的值（当不采用默认值时）。
其次，作为备份，相同的文档应包含在您的错误跟踪软件中的“如何设置版本控制软件？”下。漏洞。 （错误跟踪数据库位于不同的物理服务器上，对吧？）
第三，所有这些都应该在异地备份。我肯定有关于备份策略的问题。
【讨论】：
对提交挂钩和其他配置文件使用相同的版本控制存储库有什么问题？我过去负责项目配置管理时就是这样处理的。
您还应该备份您的 svn 存储库。这样，如果存储库本身损坏或服务器起火等，您可以恢复您的项目和 svn 控制文件。
【讨论】：
Natch - 版本控制和任何其他基础设施代码也在版本控制之下，但我会使用与任何开发项目不同的项目。
我更喜欢可搜索的 wiki 或类似的 知识库 存储库，而不是使用诸如 VCS 配置之类的东西堵塞您的错误跟踪系统。
最重要的是，确保文档保持最新 - 根据我的经验，人们在保持代码文档最新方面比管理员文档要好得多。这可能是个人所关心的。经常被忽视的一件事是，如果系统是根据标准 Unix 实践 或类似理念配置的，这意味着 OS/X 或 Windows 程序员可能不熟悉的位置知识体系，面临突然修复损坏的脚本。不要居高临下，确保记录有关位置和相互依赖性的基本假设。
【讨论】：