2

我们小组正在考虑迁移到 SVN。但是，我似乎无法找到执行以下操作的方法：

我需要在本地对存储库中的大约 20 个文件进行细微调整，而 SVN 认为它们“已更改”并包含在提交中。（通信超时和日志记录级别等更改。）

理想情况下，我希望将调整后的文件合并到存储库中的较新版本。（通过其他用户提交的更改使调整后的本地文件保持最新。）

我无法想象我们在想要/需要这个方面是独一无二的。

是否有围绕此类用例的最佳实践？

我正在考虑的一件事是将所有调整后的文件放入分支的“调整后”工作副本中。

然后将我调整过的文件合并到我的“官方”工作副本中。

然后使用比较“调整”和“官方”工作副本的脚本来更新我的忽略列表。该脚本还将取消忽略并提醒我注意任何可能需要提交到存储库的调整和其他更改的文件。

这似乎有点hacky，我无法想象没有更好的方法。

4

4 回答 4

2

每当您在存储库中有文件但您不想更改时，您最终都会更改这些文件。您使用什么版本控制系统并不重要。有人会不小心更改这些文件。

有几件事可以提供帮助：

  1. 我有一个预提交挂钩，可以防止意外更改特定文件。你说它们是只读的，如果有人试图对它们提交更改，提交将被拒绝。
  2. 也可以使用更改列表。您可以创建要修改的文件的更改列表，然后使用更改列表。当然，可能会发生意外更改（请参阅第 1 点中的预提交挂钩）。
  3. 要考虑的一件事是改变你的工作方式。如果这些调整文件有可替换的参数怎么办。然后使用您的构建系统来调整这些文件。我使用 Ant 并设置了一个build.template.properties允许人们调整构建的文件。该文件已签入，但假设开发人员将其复制到build.properties并按照他们想要的方式对其进行调整。我使用svn:ignore和我的预提交钩子来确保没有人检查实际build.properties文件。
  4. 在 Subversion 中，分支既便宜又容易。将文件放在分支上并在那里进行更改。您可以通过定期将原始分支合并回此分支来使分支保持最新。从 1.5 版开始，Subversion 具有出色的合并跟踪方法，可以防止重复合并。
于 2012-11-13T00:24:28.743 回答
1

根据您使用的语言，您是否可以不从定义值的单个文件中加载这些调整，并拥有一组提交给源代码控制的默认值，并允许每个开发人员创建自己的“调整”文件，这些文件被忽略?

这样，源代码中的版本是一致且稳定的，具有合理合理的默认值，但是开发人员可以在本地副本上调整他们的内心内容。

听起来不像是版本控制问题，更像是“我们如何获取值来覆盖可调整设置”的问题。

于 2012-11-12T21:51:47.653 回答
0

旁注：如果

我需要在本地对存储库中的大约 20 个文件进行细微调整，而 SVN 认为它们“已更改”并包含在提交中。

在您的工作流程中是相当普遍的要求，那么您可以考虑不使用 Subversion，而是使用 fe、带有 MQ+mqcollab 扩展的 Mercurial 或 hg commit 中的 -X 选项

于 2012-11-13T04:19:08.607 回答
0

只是不要提交包含设置的文件。提交作为设置的“待配置模板”的文件。然后（如果你很友好）删除一个“readme.txt”文件，解释复制模板文件，在编辑器中打开它，并设置适当的值作为文件在其注释中描述的值。

你并不是唯一需要每次安装“调整”的，但你为什么要首先提交它们。源代码控制不是“系统备份”，它是源代码控制。

PS。如果你真的需要像上面那样配置 20 个不同的文件，考虑改进你的配置控制的集中化。

于 2012-11-13T04:29:13.170 回答