源代码控制 - 开源项目

Question

我遇到了一个普遍的困境。

很多时候，我们公司依赖于使用开源库来完成任务，但偶尔我们必须修改它们以在不同平台上运行，修复错误等。

我们使用 TortoiseSVN 和 AnkhSVN 的组合。

以下情况是否有办法在 SVN 中实现：

开发人员将开源项目的源代码添加到我们的 SVN 中（通常通过导出，具体取决于他们使用的源代码控制方式）。 开发人员对开源代码进行了几个更改。 开源项目创建者进行了自己的改进和错误修复。 我们如何将开源项目的更改合并到我们的 SVN 中？

如果 SVN 无法实现此操作，那么是否有更好的源代码控制选项适合我们？ 如果可能的话，我们希望它与 Visual Studio 集成。

- jonathanpeppers

Answer 1

Subversion当然可以做到这一点。在分布式VCS出现之前，这种情况就已经发生了。请参见Subversion书中第4章。分支和合并的供应商分支部分。

引用：

“管理供应商分支通常是这样的：首先，创建一个顶级目录（例如/vendor）来容纳供应商分支。然后，将第三方代码导入该顶级目录的子目录中。然后将该子目录复制到适当的位置的主开发分支（例如/trunk）中。您始终在主开发分支中进行本地更改。每次跟踪的代码发布新版本时，都将其带入供应商分支，并将更改合并到/trunk中，在本地更改和上游更改之间解决任何冲突。”

- Peter Štibraný

---

确保我理解正确：通过“svn copy”从开源项目创建一个分支，然后合并到我们的主分支。稍后我会再次使用“svn copy”从开源项目更新分支并再次合并。听起来很简单。我会尝试一下，但我想知道其他源代码控制选项是否更好。我知道一些分布式版本控制系统可以比Subversion更好地进行合并（冲突更少），因为它们保留有关每个变更集的更多信息。 - jonathanpeppers

@Jonathan.Peppers 任何分布式版本控制系统都会更好，因为它将保留一个有向无环图的更改记录，将您的更改和开源上游更改分离，然后轻松地将它们合并在一起（而不是仅仅试图将两者压缩在一起并产生本不应存在的冲突）。此外，该模型还支持直接使用这两个上游分支进行工作的能力。 - alternative

@Jonathan.Peppers：不，你不能从不同的存储库中进行“svn copy”。您需要从已下载（或签出）源代码的稳定版本创建供应商分支。然后将它们导入您自己的 SVN。 （我同意 DVCS 更好，因为它允许您直接从远程存储库拉取更改到供应商分支，包括完整的历史记录。在 SVN 中，您无法获得完整的历史记录，并且必须手动执行“pull”操作） - Peter Štibraný

Answer 2

Subversion不是适合这里的工具。你需要一个分布式版本控制系统，可以在多个存储库之间拉取和推送，并且没有中央存储库。

查看Git和Mercurial获取更多信息。如果上游项目使用Subversion，则可以使用git-svn作为桥接器--创建自己的存储库，更改内容，仍然可以将svn合并到其中并推送到自己的“上游/中央”git存储库。

另外请注意：您为什么不直接向项目贡献您的更改？（特别是如果该项目根据像GPL或LPGL这样的许可证强制您以合适的许可证公开发布修改后的源代码，而许多项目都是如此）。这似乎是回馈提供免费代码给您的人们的好方法…

以下问题涉及Git + Visual Studio：使用Git与Visual Studio。

- alternative

---

这两个中有没有 Visual Studio 集成？ - jonathanpeppers

认为Subversion不是正确的工具是完全错误的。在Subversion中创建供应商分支（如@Peter所示）是一个完全合理和可维护的解决方案。我甚至不确定DVCS是否会在没有供应商分支策略的情况下使问题更容易管理。 - John Bledsoe

我们通过在svn仓库中分支供应商代码，应用我们的补丁，然后将任何后续的供应商更新合并到我们的修补分支来处理这个问题。我不同意subversion不适合这个工具的说法。 - SteveMc

@mathepic，是的，在svn中你必须手动进行导入（或者你可以使用SVN书中提到的svn_load_dirs.pl工具）。当然，这并不像使用DVCS那样优雅，但肯定是可行的。 - Peter Štibraný

@John Bledsoe 我什么时候说过开源版本控制系统是什么了吗？我说的是如果它恰好是Subversion，这很有可能，你可以使用git-svn。 - alternative