我想开始使用GIT-SVN与SVN存储库一起工作。我知道使用GIT的很多好处仍然存在于GIT- svn中，比如轻量级分支，改进的文件重命名/移动检测。
但是我想知道是否有我应该注意的缺点?
效益
以下是我认为它有价值的原因，尽管可能还有其他原因。
- 不需要在项目上进行提交访问就可以开始编码。
- 可以在没有提交访问权限甚至没有Internet连接的情况下在本地机器上进行版本控制。
- 更容易浏览整个修订历史记录(包括SVN历史记录)
-
git-svn rebase比SVN内置的冲突解决工具好一千倍。 你仍然可以从Git改进的分支机制中获得一些有限的好处。
缺点/strong>
最大的缺点是:确保不要做任何merge操作，否则当您尝试提交时，SVN会崩溃。另外，由于您使用rebase来与SVN存储库同步，并且由于pull从一个已经重新基于的存储库中提取会导致Git崩溃，因此维护Git主存储库的克隆要困难得多(您可能最终需要在每次重新基于后删除它们并重新克隆)
我能想到的主要缺点是最初的克隆可能非常慢，因为您克隆的是项目的整个历史。当然，对于纯git来说也是如此，但如果您是从纯git服务器克隆的，那么它就是为此而设计的。svn存储库不是，所以git-svn必须一次获取一个修订的历史。一个解决方案(除了让克隆操作运行一夜)是做一个"浅克隆"，尽管你显然没有整个历史，所以你必须使用svn log来寻找非常旧的版本。
我同意MatrixFrog的观点，速度是个问题。这是真的，尤其是当你第一次克隆一个项目时，但不仅仅是那时。
我遇到的另一个问题是git-svn本身几乎不支持svn:externals。而我能找到的最好的解决方案并不总是按照它应该的方式工作。
我还想到了几个:
- 当移动/重命名一个文件时，git不会存储任何元数据来说明"这个文件被重命名了"，它只是通过注意到旧文件和新文件非常相似来计算出来。SVN希望您通过 SVN重命名，以便它可以记录一些元数据。Git不会这样做，所以你的SVN仓库不会有它应该有的所有历史记录。
- 合并时(或者更有可能，因为Max所说的而进行挑选)，
svn:mergeinfo属性不会被设置。事实上，我认为几乎任何使用SVN属性的东西，都无法通过git-svn完成。
总的来说，它仍然比使用标准SVN客户端要好得多，但也有一些明显的缺点。