使用GIT-SVN而不是其他SVN客户端的缺点？

Question

我想开始使用GIT-SVN来处理SVN存储库。我知道使用GIT的许多好处仍然存在于GIT-SVN，如轻量级分支和improved file rename/move detection。

但我想知道是否有任何我应该注意的缺点？

Answer 1

<强>优势

这就是我发现它有价值的原因，尽管可能还有其他原因。

• 无需对项目进行提交访问即可开始编码。
• 可以在没有提交访问权限甚至是Internet连接的情况下对本地计算机进行修订控制。
• 更容易浏览整个修订历史记录（包括SVN历史记录。）
• git-svn rebase比SVN内置的冲突解决工具好一千倍。
• 您仍然可以从Git改进的分支机制中获得一些有限的好处。

<强>缺点

主要的弊端：确保不要执行任何merge操作，否则当您尝试提交时SVN会吓坏。此外，因为您正在使用rebase与SVN存储库同步，并且由于已经重新定位的存储库中的pull将导致Git异常，因此维护主要克隆更加困难Git存储库（您可能最终需要删除它们并在每次rebase之后重新克隆。）

Answer 2

我能想到的主要缺点是初始克隆可能非常慢，因为您正在克隆项目的整个历史记录。当然，纯粹的git也是如此，但是如果你是从一个纯粹的git服务器克隆的，它就是为此设计的。 svn存储库不是，因此git-svn必须一次获取历史记录一次。一个解决方案（除了让克隆操作一夜之间运行）就是做一个“shallow clone”但是你显然没有完整的历史记录，所以你必须使用svn log来寻找旧修订。

Answer 3

我同意MatrixFrog的说法，速度是一个问题。这是真的，尤其是当您第一次克隆项目时，而不仅仅是那时。

我遇到的另一个问题是git-svn本身几乎不支持svn：externals。而the best solution I could find并不总是以它应有的方式运作。

Answer 4

我想到了几个：

• 当移动/重命名文件时，git不存储任何表示“此文件已重命名”的元数据，它只是通过注意旧文件和新文件非常相似来计算出来。 SVN希望您重命名到 SVN，以便它可以记录一些元数据。 Git不会这样做，所以你的SVN回购将没有它应该拥有的所有历史记录。
• 合并时（或者更可能是因为Max所说的挑选），svn:mergeinfo属性将不会被设置。事实上，我认为几乎任何使用SVN属性的东西，你都做不到git-svn。

总的来说，它仍然比使用标准SVN客户端恕我直言更好，但有一些明显的缺点。