svn - 使用 git-svn(或类似的)*just* 来帮助进行 svn 合并？

Question

我的项目中出现了一些复杂的 subversion 合并:分离了很长时间的大分支。 Svn 提供了太多冲突 - 其中一些似乎是虚假的。

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

你能推荐其他替代方案(例如 svk 、 hgsvn )来减轻合并的痛苦吗？

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

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

提前致谢。

PS:有些帖子似乎相关(例如 git-svn merge 2 svn branches )，但他们没有完全回答这个问题。

更新:走下(和上:)这条路后，请参阅我的-新手-答案。

Answer 1

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

更新:它不仅有希望，而且取得了巨大的成功。简而言之， Linus was right 。

刚刚完成了2个相隔1.5年的svn分支的巨大合并； 3k 文件已更改，在 svn 中有大量冲突(我认为是 800 个)。

我发现 git & git-svn 是一个救星:

自动冲突解决方案:首先，它提供了更少的冲突文件(我认为是大约一半)

令人难以置信的性能

优秀 repo/branching model ，灵活的工作流程:使用各种方法轻松实验，例如逐块(及时)合并，始终进行完整性检查(编译等)；每当遇到麻烦时:只需回溯。您可以随时在需要时退后一步。

可用性，很棒的工具:

git-log(以及底层的 git-rev-parse 选项)，没有比这更强大的了。它也很方便:-p 一次性为您提供差异；在 svn 中你会得到一个日志，然后找到那个“revision-1:revision”的差异，或者使用笨拙的用户界面。查找何时将字符串添加/删除到 repo 中，同时搜索多个分支

gitk :结合强大的搜索功能，对于可视化分支历史非常有用。在其他工具中还没有看到过这样的东西，尤其是没有这么快。没关系它在 Tk 中，它只是很棒

git gui:即使不是最性感的也能正常工作 - 对新手发现事物有很大帮助

blame :奇迹。是的，它检测原始段的来源(复制和粘贴等)

mergetool :比启动大 svn merge 更令人愉快的体验，然后每次(即每 5 分钟)它遇到冲突时停止，按“(p)ostpone”，而不是稍后手动搜索冲突文件。首选集成在 git gui 中的这种风格(为此需要 tiny patch)。
发现集成外部差异工具比 svn 中的可配置性更好。

可插拔合并驱动程序和对它们的细粒度控制

rebase 允许过滤掉 svn 历史记录中更困惑的部分

分布:做这个的时候不用来办公室，可以在火车/飞机等上暂停和一步步前进。

带有 Unison 的 USB 驱动器使同步工作<->回家小菜一碟

如果没有 git 的疯狂压缩，这是不可能的(5 年的项目，提交 26k，大量的分支和二进制文件，主干 svn checkout:1.9Gb => 所有这些都在完整的 git 仓库中:1.4Gb!)

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

尽管我不能强制公司里的每个人都立即转换——其实我真的不打算这么做。再次， git-svn 通过“先试探”的方法拯救了我们。但看到同事的 react ，转换可能会在任何人预期之前发生:)

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

警告:

"Do not dcommit Git merge commits to the Subversion repository. Subversion doesn’t handle merges in the same way as Git, and this will cause problems. This means you should keep your Git development history linear (i.e., no merging from other branches, just rebasing)." (last paragraph of http://learn.github.com/p/git-svn.html )

另一个很好的来源是 Pro Git book ，“切换事件分支”部分基本上说合并确实有效，但 dcommit 只会存储合并的内容，但历史将受到损害(这会破坏后续合并)，因此您应该删除合并后的工作分支。
无论如何，这毕竟是有道理的，而且在实践中很容易避免这里的陷阱..在 svn 中，我发现人们通常不会重新合并，因此如果您首先来自 git world，这只能被视为退后一步地方。

无论如何，dcommit 对我有用。我在我自己的 svn 工作分支上做了它，我只保留了这个，所以当时避免了任何额外的冲突。但是，我决定从这个工作分支到 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's builtin mergetool integration(在冲突中右键单击文件)。不过，这有点有限，所以请参阅我上面的小补丁，它允许您插入一个 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

哎呀，这太长了，早点停下来为时已晚..祝你好运。