目前我们有一个具有以下布局的Subversion版本库：
我相信这是一个相当糟糕的布局，但目前很难完全改变它。
就我个人而言，我不喜欢颠覆，主要是由于检查历史需要很长时间，而且分支和合并也很麻烦等等，所以我真的想用git来代替。
可悲的是，我们不能转换为git，因为一些人的心理能力可能会压倒一切，所以我正在研究git-svn，看看我是否可以用它来解决问题。
可悲的是，直接结束了糟糕的情况，因为我想把每个项目分解成一个git仓库，而且我不想在每台我工作的计算机上重新创buildgit-svn结帐。 所以我虽然也许有可能创build某种透明的git←→svn代理/网关，以便推动该回购“提交”svn回购，并提交到svn回购更新git回购。
谷歌并不是我的朋友，只find通用的使用帮助使用git-svn，所以我问你是否有一些好的想法来完成这一点。
对于透明的Git / Svn网关，你可以使用SubGit ，除了现在它只支持简单的单一项目（/ trunk，/ branches，/ tags）或者多项目（/ project / trunk， …）布局。
如果你不控制或不想弄乱Subversion服务器，那么你不能使用SubGit。 你可以在这种情况下做的是有一个自动同步的每个中继的git仓库。 我们的团队是这样工作的 – 我们有一个git-Subversion桥梁，它可以同步团队git存储库和公司Subversion存储库中的项目中继之间的变化，以便我们的git使用对其他Subversion用户是透明的。
该设置在https://github.com/mrts/git-svn-bridge中有更详细的描述。
我们已经在生产中使用了这个设置了一年多了。
我想最大的警告是git分支将在合并到主干期间被压缩到一个提交。 对我们来说，这是没有问题的 – 我们使用短命任务分支，并认为它们是轻量级，短暂的“工作单元”，可以在单个块中进入主线 – 并将分支历史保留在git中。
你基本上有两个select：
在客户端允许git-svn来解决问题。 你的初始结账需要一段时间，但它可以给你所有相同的function，本地svn结帐（包括通过git svn dcommit和git svn [fetch|rebase]推和拉），如果你用--stdlayout ，您可以获得完整的分支和标记支持。 （我是在我的公司工作 – 我是使用svn服务器的git的两名员工之一，我没有任何问题。）
用git-svn克隆仓库到另一台服务器（甚至是同一台服务器），然后从这个仓库开始托pipegit。 然后你有一个本地的git回购，所有的svn数据都在之前。
如果你不想在每台计算机上“git svn clone”，你可以：