分布式团队的源代码管理文件夹组织答案

【问题标题】：Source Control folder organisation for distributed team分布式团队的源代码管理文件夹组织
【发布时间】：2011-02-01 08:06:16
【问题描述】：

我们的团队分布在两个地理位置。我们共享和使用类似的脚本来自动化我们执行的不同测试。我们最近决定使用源代码管理来管理正在使用的不同脚本。到目前为止，我们生成的任何脚本都被共享到另一个位置，他们会根据他们的需要进行小的本地修改并使用它。也就是说，我们将使用相同版本的脚本，只针对我们的本地设置进行一些小的修改。如何最好地在源代码管理中组织它。我们计划将 Subversion 与跨两个位置复制的存储库一起使用。

我想到的一个解决方案是为每个位置创建两个文件夹。因此，他们上传的任何脚本，我们将复制到我们自己的目录并进行本地修改。还有其他建议吗？

谢谢...

【问题讨论】：

标签： svn version-control

【解决方案1】：

您应该有一个存储库来保存脚本。每个修改（由本地或远程团队）都会被版本化。更改可以回滚。您将拥有修订历史记录等。多个文件夹破坏了拥有版本控制系统的目的。当然，您可以有子文件夹来逻辑分离脚本。

如果网络性能是个问题，您可能需要查看分布式版本控制系统，例如 git 或 mercurial。

【讨论】：

我们将使用相同版本的脚本，并针对该位置进行一些小的修改。更新它们时不会在每个位置使用不同的修订版造成混乱吗？我非常想使用 Git，但我们公司还不支持 :( ...
@Manoj。您应该尝试参数化或移出脚本中特定于位置的条目。这些条目可以保存在本地，而不是签入存储库。

【解决方案2】：

这就是每个站点的分支的样子。
每个站点都对其分支拥有完全所有权，您可以导入/合并站点分支中的一个站点所做的更改。

除了使用集中式 VCS，最好远程访问 SVN 存储库（对于其中一个站点），以避免两个手动克隆之间的任何历史记录差异。

作为Raghuram，Git 或 Mercurial 更适合这种情况。

【讨论】：

每个站点的分支 - 这意味着我们将从一个主干开始，为每个站点创建一个分支并继续修改它。我们可以从另一个分支中提取所需的更新和修改。分支永远不会合并到主干？对吗？
@Manoj：是的，如果您不需要在主干上进行这些修改，您将永远不会合并它们。但是，如果在远程站点上进行了一些改进，您可以查看这些并将它们合并到您自己的分支中。

【解决方案3】：

我没有使用过 SVN，但与其他许多 vcs 系统和...

我同意优先级应该是“您应该尝试参数化或移出特定位置的条目”，但首要任务是将所有脚本置于公共存储库中的源代码控制之下。事实上，您的流程文档也应该受到源代码控制。

我之前加入了一个 CM 团队，该团队未能将 CM 工具用于他们自己的脚本。果然，我们经常会发现一个问题，即并非所有成员都会为相同的任务使用相同的脚本。将脚本和文档放在存储库中可以方便和轻松地让每个人都使用相同的工具并保持最新状态。

要通用化您的脚本等，请为具有 common/site A/site B/ 结构的脚本创建一个文件夹树。将各个站点的所有脚本放在目录下。然后将相同的脚本迁移到“通用”并从其他脚本中删除并检查所有内容。最终目标是将所有脚本移动到通用代码库。实现这一目标的通用去本地化框架或模板将加快这一过程。您会发现，一旦完成了前几个，其余的就会很快跟进。拥有单独的目录可以让您轻松区分本地化并消除它们。

您不希望处于用户必须不断合并（呃！）并覆盖其语言环境的本地化数据或更糟糕的是在结帐后手动执行的情况。最理想的情况是，在更新任何脚本时，应该考虑到去本地化的目标，所以除非有情有可原，否则只接受对 common 的更新；还强制更新程序在做一侧时更新 A 和 B 分支。您会发现人们厌倦了重复做某事（为了别人的利益），并且很容易开始对脚本进行去本地化。

【讨论】：