Question

我在一家SVN商店工作，但为了在工作中注入一点理智，我使用git-svn。越来越多的同事也看到了光明，现在我们想要在某些情况下完全支持SVN。目前我们每个人都拥有自己的git-svn仓库，但由于差异很大，我们无法真正分享除普通补丁或SVN之外的任何东西。我们应该如何组织我们的回购以便直接共享（通过git-remote）？

我能想到的唯一方法是使用单个共享git-svn repo，我们将其用作SVN的网关，但这可能有点麻烦 - 它会更好如果我们都可以直接从我们自己的git-svn repos推送到SVN。

编辑：不幸的是我没有SVN服务器的管理员权限，所以目前很少使用像 subgit 这样的解决方案，即使它们很有意思

Answer 1

您可以查看subgit：

SubGit是一个平稳，无压力的Svn到Git迁移的工具。在服务器端安装一次，并根据需要使用Subversion和Git。

SubGit允许用户设置双向Subversion到Git复制（可写镜像）。

和

SubGit是一个从Svn到Git的公司范围迁移的解决方案：

Much better than git-svn (see comparison);
Requires no changes of the infrastructure that is already in place;
Allows one to use all Git and all Subversion features;
Provides genuine stress-free migration experience.

Answer 2

如果我们都可以直接从我们自己的git-svn repos推送到SVN，那就好了。

不是git svn dcommit命令的用途吗？

使用git svn rebase将git clone重新绑定到中央svn repo，然后使用git svn dcommit将本地提交推送到svn。

我每天都使用git svn GCC git mirror并且效果非常好。也许那是因为有一个中央只读镜像，它会自动从svn提交更新，所以使用git-svn的每个人都可以从git镜像和同一组commit-id看到相同的历史记录。这允许从只读镜像获取和合并，然后只是git svn rebase和git svn dcommit将更改推送到svn repo。然后，这些更改将同步到只读镜像，并由具有相同ID的其他所有人提取。

Answer 3

两个不同版本控制系统之间的双向网关早于git。大约10年前，我已经在CVS和Arch之间手工完成了这项工作。如果您不想购买subgit，可以手动维护网关，甚至尝试编写脚本。工作流程很简单：

有两个分支，trunk和master。 trunk镜像颠覆，master加上git
每当subversion发生新的变化时：
1. $ git svn fetch
2. master$ git merge trunk
每当推动行李箱时：
1. trunk$ git merge master
2. trunk$ git svn dcommit
3. master$ git merge trunk
您应该以原子方式执行这两个序列，即一次只执行一个操作。
您可以考虑设置git-svn，以便不使用subversion修订信息重写提交，以减少git中的合并提交次数。
可以为多个分支完成，但我不认为在git中合并单独的subversion分支可以工作。

Answer 4

我们处于完全相同的情况。我们拥有的是（警告，一些伪代码！）：

远程git repo，脚本化（使用bash脚本），不能是--bare
一个预接收挂钩，用于检查用户名，然后根据收到的每个ref和所有SVN映射的分支:( git - ＆gt; svn）：
- git checkout -f <branch>
- git reset HEAD --hard
- git clean -fdx
- git merge -n $newrev
- git svn dcommit
- 如果失败，请全部还原，
- 然后，在所有循环之后 - 更新所有SVN分支（使用脚本，见下文）
使用最新的svn更改（svn - ＆gt; git）更新git-svn分支的cronjob：
- git checkout --orphan svn-update <random-branch-name>
- git svn fetch --all
- 适用于所有git-svn分支：git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch>，
用于git身份验证的ssh密钥
用户管理的SVN身份验证（基于git用户名，这取决于您的设置）

这样没有人直接使用SVN，与纯git的唯一区别是你不能改变git-svn分支历史（因为SVN不会让你这么说）。

Answer 5

我处于类似的设置中，这是一个适合我和我工作的人的过程：

一个人使用git svn clone和朋友创建一个Git存储库。
其他人使用常规Git命令克隆第一个Git存储库，然后复制第一个存储库svn-remote.{name}的{{1}}位。在.git/config。

现在，每个人都有git help svn设置，可用于与Subversion存储库进行交互。

更重要的是，每个人都有git-svn设置，具有相同的分支和提交历史记录，这意味着git-svn和朋友创建的提交将是相同的，包括哈希 。此时，除了推送和拉动Subversion存储库之外，您还可以使用所有Git的发烧友分布式功能。

与常规Git不同，你需要小心共享配置 - 如果你的分支结构发散，你的哈希也会分歧。偶尔会出现问题并且需要修复（我曾经有两个git svn fetch同时进行攻击，其中的每个人都以微妙的方式工作;我不得不用git svn fetch回溯我的历史记录并重新填写为了保持我的哈希与其他人的匹配）。但它们是将两种工具混合在一起的限制。

Git用户在SVN商店，组织我们的回购

5 个答案: