2

该组织正在考虑从 Visual Source Safe 迁移到 Subversion。VSS 中的当前方法使用同一个本地 Netbeans 项目来处理 dev、qa 和发布代码，并将更改从本地项目（例如 P:\test）上传到适当的 VSS 项目（例如 dev）。在网上查看时，我可以看到大量描述将 SVN 指向共享代码库的资源，例如此处或此处，但与其他项目一样，这似乎是在多个项目之间共享资源，而不是将单个代码库指向多个存储库上的项目。

我的直觉是，最好让每个项目在本地（即 dev、qa 和 release）指向一个特定的存储库，并将需要从 dev 移动到 qa 的文件复制，而不是尝试复制 VSS 方法一个本地项目用于保存多个存储库代码库。任何意见都非常感谢！

4

1 回答 1

0

Subversion 根本不支持在存储库之间复制文件。为同一个项目维护 3 个存储库将陷入疯狂。

您也不想拥有“多个代码库”——这都是一个代码库，您只需要有一个清晰的流程来将您的更改从 dev 转移到 qa 再到发布。为此，您需要标签和分支的组合。定期合并更改。确切的实现将归结为您如何管理应用程序的开发，这可能需要改变一些。因为您将不得不取消学习在使用 VSS 时学到的所有内容，因为 VSS ......嗯，它很烂。

有以下假设：

  • 在积极开发期间，所有开发人员都在一个共同的代码库中工作
  • 你有一种方法可以说“好的，我们这里的东西已经准备好进行 QA 测试了”
  • 您需要继续开发，同时还要修复 QA 中的错误
  • 一旦某样东西投入生产，你就不能在不经历整个过程的情况下改变生产中的东西（如果你没有这个，总有一天你会一团糟）

我会推荐以下内容：

  1. 按照手册中的描述创建“传统的”主干/分支/标签结构。所有开发人员都从主干中签出以进行常规开发工作。真的，请阅读手册的整个章节（两次），因为它是我在此处列出的内容的更长、更详细的版本。
  2. 当您决定是时候将发布推送给 QA 时，通过将主干复制到branches. 你如何命名这取决于你，但要清楚和一致。例如，如果您正在为一个名为 4.2 的版本进行分支，则可以将其命名QA-4.2（下次您为 4.3 进行分支时，将其命名QA-4.3，依此类推）。
  3. 如果（当）您在 QA 测试中发现错误，则将它们作为针对QA-4.2分支的补丁进行修复。负责这件事的人需要检查第二个工作副本以进行这些更改并将它们提交到分支。
  4. 定期将您在 QA 分支中制作的补丁合并回主干。否则，您在 4.2 中修复的那些错误将在 4.3 中重新出现。
  5. 当您在 QA 中的代码已通过所有测试并可以用于生产时，通过将 QA 分支复制到tags目录中来创建标签。您可能希望与您在 QA 中所做的事情保持一致，使用名称tags/4.2-RELEASE或类似名称。然后发布你的新版本。
  6. 现在可能是svn merge --reintegrate在您的分支上使用的时候了，然后可能删除该分支。代码已经发布，我们现在正在进入下一个版本。
  7. tags目录中的内容不会改变。如果有人在生产中发现错误，您可以像处理任何新开发一样处理它。否则这些更改将无法返回到主干（除非有人非常仔细地观察）并且错误会卷土重来。

Subversion 项目自己如何创建和维护他们的发布分支也可能是有益的。

于 2013-08-06T01:48:53.567 回答