5

我刚想到这个古怪（愚蠢？）的想法，我想同时使用 Git 和 Subversion 跟踪同一个文件夹（项目）；也就是说文件夹/项目将同时具有.svn和.git目录。

我在搜索中没有找到任何相关的东西，所以这就是为什么我在这里提出这个想法来评估它的利弊（如果有的话）。我可能正在寻找的是：为什么不能或不应该使用这种策略？

问：我为什么要这样做？

我们已经在网络上有一个 Subversion 存储库，具有超过 1 年的历史 + svn:externals + 链接到错误跟踪 + 挂钩。但我希望拥有 DVCS 的灵活性，例如 Git，这样我们就不必连接到网络来提交我们的工作；这样我们也可以远程工作。

问：但是我可以使用 git svn！

不幸的是，Git svn 不支持 svn:externals。并且 git 子模块与 svn:externals 不同。

问：这种组合可以实现什么？

Git的灵活性：无需连接网络即可在本地编辑和提交代码；此外，将 repo 推送到生产或登台服务器或同事将是小菜一碟。

SVN的中心化和外部repo利用：通过SVN:externals的有效利用，我们将为自己节省大量工作，然后开发人员已经熟悉SVN。

理想情况下，我希望最终完全切换到 Git，但就目前而言，因为 svn:externals 使得集成外部存储库变得超级容易，保持颠覆完整是有意义的。

4

3 回答 3

5

这个策略绝对有效；我用过它，虽然时间很短，而且我知道我公司的其他开发人员已经用了很长时间。然而，这并不意味着它很容易。

你会发现你需要做很多工作才能让 Subversion 和 Git 保持同步。举个简单的例子：当你执行一个 时svn update，你还需要执行一个git commit -a或类似的操作，否则 Git 会认为你的工作副本有大量的更改，Subversion 知道这些更改与远程存储库是最新的。

svn update -r如果您出于某种原因需要查看旧版本，或者尝试使用svn switch等，这会变得更加复杂。

根据您是否让 Git 跟踪您的.svn目录，您会遇到其他问题。如果您不这样做（即，您放入.svn您的.gitignore文件或类似文件），您会发现使用 Git 的分支功能要困难得多。考虑以下工作流程：

  1. 创建一个 Git 分支来处理一个特性。
  2. 您需要修复 Subversion 存储库中最近签入的错误！切换回你的 Git 主分支，svn up然后git commit，你就有了最新的代码，修复了这个 bug，git commit然后svn commit就可以了。
  3. 再次检查您的 Git 功能分支。由于这是基于不同的 Subversion 版本，Subversion 现在认为工作副本中有大量更改。

或者，您可以让 Git 跟踪.svn目录。这避免了上述问题——当您在第 3 步再次检出功能分支时，您还将检出当时的 Subversion 元数据，因此 Subversion 知道所有内容所基于的正确修订版。

可悲的是，Subversion 从来没有被设计成以这种方式使用。在 Subversion 1.6（我不知道 1.7）中，.svn目录可能包含大量的空文件夹。Git 不跟踪空文件夹，因此这些可能会在 Git 操作之间丢失，从而破坏 Subversion 工作副本。我认识一个开发人员，他编写了一堆脚本来修复这些损坏.svn的目录，但这并不是微不足道的，而且非常脆弱。

于 2013-01-24T17:47:31.663 回答
1

Git 和 Svn 可以很容易地存在于一个目录中。在 .gitignore 中忽略所有 .svn 目录，在 svn 中忽略 .git 目录。我以前用过它，直到我意识到我不再需要 SVN。

于 2013-01-24T12:41:47.157 回答
1

我认为您不会遇到任何冲突，但您的 SVN 存储库不会包含 GIT 存储库的提交。

例子：

离线时，开发人员使用 GIT 中的描述性提交消息执行 5 次提交。
现在，SVN 重新上线，他想将更改保存到 SVN。他现在要么使用描述性较少的消息进行一次提交，要么必须通过将他的工作副本重置为那些特定的提交并将它们中的每一个提交到 SVN 来重复他在 git 中所做的提交。

于 2013-01-24T12:11:07.203 回答