使用 git-svn （或类似的）*只是*来帮助进行 svn 合并？

Question

我的项目中出现了一些复杂的颠覆合并：已经分开很长时间的大分支。 Svn 给出了太多的冲突——其中一些看起来是虚假的。

---

鉴于 git 因卓越的合并体验而受到称赞， 仅为了使合并更易于管理而使用 git-svn 有什么好处吗？

---

您能否推荐其他替代方案（例如svk、hgsvn）来减轻合并痛苦？

有些冲突很容易解决（例如 java 导入、空格） - 所以我也想知道是否有任何自动化解决方案。

将来可能会完全转向 DVCS（我们中的一些人会喜欢这样），但不是现在。 （更新：这不再是真的 - 团队最近完全切换并且对此感到高兴）。

提前致谢。

PS：有一些帖子似乎相关（例如git-svn merge 2 svnbranch ）但他们没有完全回答这个问题。

更新：沿着这条路向下（和向上：）后请参阅我的-新手-答案。

Answer 1

试图回答我的问题：使用 git 进行 svn 合并似乎很有希望。

更新：这不仅是有希望的，而且是巨大的成功。简而言之，Linus 是对的。

刚刚完成了2个相隔1.5年的svn分支的大规模合并； 3k 文件被更改，在 svn 中出现大量冲突（我认为大约有 800 个）。

我找到了 git & git-svn 救星：

• 自动冲突解决：首先，它提供了很多较少冲突的文件（我认为是一半）
• 令人难以置信的性能
• 出色 repo/分支模型，灵活的工作流程：轻松试验各种方法，例如逐块（及时）合并，始终进行健全性检查（编译， ETC）;每当遇到麻烦时：就原路返回。当需要的时候，你总是可以后退一步。
• 可用性，出色的工具：
  • git-log（以及底层的git-rev-parse选项），没有什么比这更强大的了。它也很方便：-p 一次性为您提供差异；在 svn 中，你会得到一个日志，然后找到“revision-1:revision”的差异，或者使用笨拙的 UI。查找何时将字符串添加到存储库中/从存储库中删除，同时搜索多个分支
  • gitk：对于可视化分支历史非常有用，并具有强大的搜索功能。在其他工具中没有见过这样的东西，尤其是没有这么快。别介意它是 Tk 的，它太棒了
  • git gui：即使不是最性感的，也能正常工作 - 对新手发现事物有很大帮助
  • 责备：奇迹。是的，它会检测原始片段的来源（复制和粘贴等）
  • mergetool：比启动大型 svn merge 更愉快的体验，然后每次（即每 5 分钟）遇到冲突时都会停止，按 '( p)ostpone'，而不是稍后手动寻找冲突的文件。更喜欢集成在 git gui 中的风格（需要一个小补丁为此）。
    发现集成外部 diff 工具比 svn 中的可配置性更好。
  • 可插入合并驱动程序及其细粒度控制
  • rebase 允许过滤掉 svn 历史记录中更混乱的部分
• 分布的混乱部分：处理此问题时无需到办公室，可以暂停并继续工作。在火车/飞机等上逐步进展。
  • 带有 Unison 的 USB 驱动器可实现同步工作<->家庭小菜一碟
  • 如果没有 git 的疯狂压缩，这是不可能的（5 年历史的项目，有 26k 次提交，大量分支和二进制文件，主干 svn 签出：1.9Gb => 所有这些都在完整的 git 存储库中：1.4Gb ！）

所以，这确实可以从噩梦变成快乐 - 特别是如果你喜欢学习（在这种情况下确实需要一些努力 - 我想就像在学习自行车之后学习摩托车一样）。

尽管我不能强迫公司里的每个人都立即转换——我实际上并没有打算这么做。再次，git-svn 通过“先涉足”的方法拯救了我们。但是看到同事的反应，这种转变可能会比任何人预期的更早发生:)

我想说 - 即使我们忘记了合并&提交，这个东西作为查询、可视化、备份等的只读前端已经很棒了。

注意：

“不要将 Git 合并提交到
Subversion 存储库。颠覆
不以同样的方式处理合并
就像 Git 一样，这会导致问题。
这意味着你应该保留你的 Git
发展历史线性（即，没有
从其他分支合并，只需
变基）。”
（http://learn.github.com/p/git-svn.html 的最后一段)

另一个优秀的来源是 Pro Git 书籍，“切换活动分支”部分' 基本上表示合并确实有效，但是 dcommit 只会存储合并的内容，但历史记录会受到损害（这会破坏后续合并），因此您应该在合并后删除工作分支。
无论如何，这毕竟是有道理的，并且在实践中很容易避免这里的陷阱..在 svn 中，我发现人们通常不会重新合并，所以如果你一开始就来自 git 世界，这只能被视为退一步地方。

不管怎样， dcommit 对我有用。我在我自己的 svn workbranch 上做了这件事，我只保留这个分支，所以避免了当时任何额外的冲突。然而，我决定从这个工作分支到 svn 中的 svn 主干进行最终合并（在同步 git 中的所有内容之后）； --ignore-ancestry 给出了最好的结果。

更新：正如我后来发现的，上面的最后几个步骤（额外的 svn 分支和合并--ignore-ancestry）很容易通过保持你要从线性中删除的分支来避免。正如 Gabe 下面所说，merge --squash 只是创建一个简单、愚蠢的 svn 友好提交。就在我的本地分支准备好进行大规模合并时（这可能需要几天/几周的时间），我现在只想：

git checkout -b dcommit_helper_for_svnbranch  svnbranch
git merge --squash huge_merge_work_with_messy_nonlinear_history
git commit 'nice merge summary' # single parent, straight from the fresh svnbranch
git dcommit

我知道合并跟踪在 svn 端不会很好地工作，直到我们完全切换。我等不及了。

---

更新：@Kevin 要求提供有关合并 svn 分支整个过程的更多详细信息。那里有很多文章、帖子，但作为新手，我发现了一些令人困惑/误导/过时的内容.. 无论如何，我这些天的做法（当然，在合并事件之后，一直使用 git-svn；就像一些新感染的同事一样）..

git svn clone -s http://svn/path/to/just-above-trunk  # the slowest part, but needed only once ever..you can every single branch from the svn repo since revision #1. 2) 
git svn fetch          # later, anytime: keep it up to date, talking to svn server to grab new revisions. Again: all branches - and yet it's usually a faster for me than a simple 'svn up' on the trunk:)    
# Take a look, sniff around - some optional but handy commands:
git gui   &    # I usually keep this running, press F5 to refresh
gitk --all     # graph showing all branches
gitk my-svn-target-branch svn-branch-to-merge    # look at only the branches in question
git checkout -b my-merge-fun my-svn-target-branch  # this creates a local branch based on the svn one and switches to it..before you notice :)
# Some handy config, giving more context for conflicts
git config merge.conflictstyle diff3
# The actual merge.. 
git merge  svn-branch-to-merge    # the normal case, with managable amount of conflicts
# For the monster merge, this was actually a loop for me: due to the sheer size, I split up the 2 year period into reasonable chunks, eg. ~1 months, tagged those versions ma1..ma25 and mb1..mb25 on each branch using gitk, and then repeated these for all of them
git merge ma1   # through ma25
git merge mb1   # through mb25
# When running into conflicts, just resolve them.. low tech way: keep the wanted parts, then "git add file" but you can
git mergetool   # loops through each conflicted file, open your GUI mergetool of choice..when successful, add the file automatically.
git mergetool  my-interesting-path # limit scope to that path

实际上，我更喜欢使用 'git gui 的内置合并工具集成（右键单击文件 ）冲突中）。不过，这有点有限，所以请参阅上面的我的小补丁，它允许您插入一个 shell 脚本，您可以在其中调用您喜欢的任何合并工具（我有时会并行尝试各种它们，因为它们引起了令人惊讶的悲伤......但通常我被 kdiff3 困住了。

当合并步骤顺利（没有冲突）时，合并提交会自动完成；否则，您将在

git commit  # am usually doing this in the git gui as well.. again, lightning fast.

最后一个阶段解决冲突。请注意，到目前为止我们只有本地提交，没有与svn 服务器还没有。
除非您使用过 --squash 或其他技巧，否则您现在最终会得到一个图表，其中您的合并提交有 2 个父级：您的 svn-mirror 分支的提示。现在这是常见的问题：svn只能获取线性历史..所以'git-svn'通过删除第二个父级来简化它(在上面的情况下是svn-branch-to-merge)..所以真正的合并跟踪是在 svn 方面已经消失了..但在这种情况下就可以了。

如果您想要一种更安全/更干净的方法，这就是我之前的代码片段的用武之地：只需使用 --squash 进行最终合并。将较早的一个适应了这个流程：

git checkout -b dcommit_helper_for_svnbranch my-svn-target-branch  # another local workbranch.. basically needed as svn branches (as any other remote branch) are read-only
git merge --squash my-merge-fun  
git commit 'nice merge summary' # single parent, straight from the fresh svn branch
git dcommit  # this will result in a 'svn commit' on the my-svn-target-branch

哎呀，这太长了，在太晚之前停止......祝你好运。

Answer 2

我自己刚刚经历过这个。 更简单的方法是通过git merge --squash 选项，它将执行合并而不记录合并提交，保持历史线性，以免混淆 git-svn。

我的合并也非常大，我必须设置 git config diff.renamelimit 0 以便 git 能够正确找到所有重命名。

Answer 3

有一些新工具可以解决 git-svn 的许多问题，并为使用 Subversion 和 Git 提供更好的体验。

除其他外，这些工具还解决了一些分支和合并问题。以下是概述：

1. git-svn

   来自文档：

   <块引用>

   注意事项

   ...

   不建议在您计划提交的分支上运行 git merge 或 git pull。 Subversion 并不代表以任何合理或有用的方式进行合并；因此使用 Subversion 的用户无法看到您所做的任何合并。此外，如果您从作为 SVN 分支镜像的 git 分支合并或拉取，dcommit 可能会提交到错误的分支。

   不进行合并提交的主要原因有以下三个：

   • git-svn 不会自动发送合并分支的 svn:mergeinfo 属性。因此 Subversion 无法跟踪 git 执行的合并。这包括正常的 Git 合并和樱桃选择。

   • 由于 git-svn 不会自动转换 svn:ignore、svn:eol-style 等 SVN 属性，因此合并提交在 Git 中没有对应的元数据。因此，dcommit 不会将这些属性发送到 SVN 存储库，因此它们会丢失。

   • dcommit 始终将更改发送到合并提交的第一个父级引用的分支。有时，更改会出现在用户意想不到的地方。

2. SubGit

   SubGit 是一个 Git-SVN 双向服务器端镜像。

   如果可以本地访问 Subversion 存储库，则可以将 SubGit 安装到其中：

   $ subgit 配置 $SVN_REPOS
   # 调整 $SVN_REPOS/conf/subgit.conf 以指定您的分支和标签
   # 调整$SVN_REPOS/conf/authors.txt指定git & svn 作者映射
   $ subgit 安装 $SVN_REPOS
   ...
   $ 安装成功
   

   此时，SubGit 将 Subversion 存储库转换为 Git（它也以相反的方向工作）并安装 SVN 和 Git 挂钩。结果，Subversion 和 Git 存储库是同步的：每次提交和推送都会启动挂钩，立即转换传入的修改。

   SubGit 将 svn:ignore 属性转换为 .gitignore 文件，将 svn:eol-style 和 svn:mime-type 属性转换为 .gitattributes，因此 Git 中的合并提交会保留此元数据。

   当一个人推送合并提交时，SubGit 会将所有新提交转换为 Subversion 修订版本。它遵循 svn:mergeinfo 属性，因此 SVN 之后可以正确跟踪合并操作。

   即使用户推送非常复杂的 Git 历史记录，SubGit 也会转换所有提交，保持合并跟踪数据有效。我们曾经一次性推送了 git.git 存储库的整个历史记录，并且它已正确转换为 SVN。

   SubGit 是一个商业产品。对于开源和学术项目以及最多 10 名提交者的项目来说，它是免费的。

   有关更多详细信息，请参阅 SubGit 文档 和 git-svn 比较页面。

3. SmartGit

   SmartGit 是 git-svn 的客户端替代方案。

   SmartGit 还支持 svn:ignore、svn:eol-style 和 svn:mime-type 属性转换。它还为合并提交设置 svn:mergeinfo 属性。它甚至更新了选择性提交的必要合并跟踪数据。

   SmartGit 是一个商业 Git 和 Mercurial 客户端。非商业用途免费。

全面披露：我是 SubGit 开发人员之一。