许多不相关文件的版本控制

Question

我很想让人们了解如何在Matlab中管理不相关函数的版本控制。

我保留了一组相当大的通用脚本，每个脚本或多或少独立于其他脚本。我一直将它们全部保存在一个目录中，在Mercurial中包含一个存储库。我开始合作了很多，我希望我的协作者能够修改文件，提交，分支和合并。

问题是文件彼此独立。从本质上讲，它们就像许多独立的小项目。但Mercurial将存储库视为单个实体。因此，如果协作者修改文件A和B，并且我只想合并文件A中的更改，事情会变得复杂。我知道我可以从协作者合并，然后还原文件B，但我想知道是否有一种更简单的方法来处理这种设置。

我可以设置许多小型存储库来单独管理每个文件，但这也很复杂。

我愿意改变版本控制系统（虽然我很喜欢Mercurial）。有什么建议吗？

Answer 1

在每个错误修复/功能添加之后检查代码被认为是最佳实践。鉴于您的文件实际上是独立的“项目”，因此错误或功能似乎不会跨越多个文件。您可以做的最好的事情是鼓励您的同事在最佳实践中同时仅针对单个文件提交更改。解释一下，关于签入的更好规则会导致更易于管理的源代码控制。希望你能够最大程度地遵循这种做法，而那些顽固的人只是停止了他们的承诺。

Answer 2

这实际上取决于合并一个更改而不是另一个更改的典型原因。如果您正在使用它来创建软件配置，即有时您想使用文件A的版本1和文件B的版本2，有时它是相反的，那么您可能想要使用subrepos来保存每个文件。如果是因为您永远不想接受协作者变更的一部分，那么他们需要被告知如何使他们的变更更具凝聚力并单独提交。对于那些之前没有使用过源代码控制的人来说，或者习惯于像svn那样习惯于源代码控制的人来说，这对于变更集的内在概念很少或根本没有。

Answer 3

这取决于您是否要维护文件的单个“主”版本，合并您喜欢的更改并忽略其他更改。如果协作者想要开发其他分支，那么他们应该克隆存储库，然后您可以接受主服务器中所需的变更集。

如果您想要否决其他协作者的更改，则需要将更改分开（通过克隆的存储库或分支），或者在将更改推回到主干之前需要进行审核。

Answer 4

我总是将传入存储库用于协作者。它们与另一个人所做的相符，但它避免了弄乱我自己的存储库。执行此操作后，您可以使用移植扩展名将新的更改集添加到您自己的存储库中。