我的项目即将进行一些复杂的svn合并：长时间分开的大型分支。Svn给出了太多的冲突，其中一些似乎是虚假的。
考虑到git在合并体验方面的优越性，仅仅出于使合并更可管理的好处，使用git-svn是否有所帮助？
您能推荐其他替代方案（例如svk，hgsvn）来减轻合并痛苦吗？
某些冲突很容易解决（例如java导入，空格），因此我也想知道是否有任何自动化解决方案。
将来可能会完全切换到DVCS（我们中的一些人会喜欢这样做），但现在还没有。（更新：这不再是真实情况-团队最近完全转换并对此感到满意）。
预先感谢您。
PS：有一些帖子似乎与此相关（例如git-svn merge 2 svn branches），但它们并没有完全回答这个问题。
更新：在经历过这条路之后，看到我这个新手的答案（上升：）。
git-log（及其基础的git-rev-parse选项），没有比这更强大的东西了。它也很方便：-p可以一次性给出差异；在svn中，您会得到一个日志，然后找到该“修订版-1：修订版”的差异，或使用笨拙的用户界面。同时搜索多个分支，查找字符串何时添加/删除到存储库中gitk：非常有用，可以可视化分支历史记录，结合出色的搜索功能。在其他工具中都没有看到过这样的东西，特别是没有这么快。不要介意它在Tk中，它就是太棒了git gui：即使不是最性感的，也可以正常工作-对于新手发现东西非常有帮助blame：一个奇迹。是的，它会检测原始段来自哪里（复制&粘贴等）mergetool：比启动大型svn merge要愉快得多，后者每次（即每5分钟）遇到冲突时都会停止，按“(p)ostpone”按钮，然后稍后手动搜索冲突文件。更喜欢在git gui中集成此类工具（需要进行小修补程序）。
发现与svn相比，集成外部差异工具更易配置。rebase允许过滤掉较混乱的svn历史记录部分因此，这确实可以使从噩梦到喜悦的差别——特别是如果你喜欢学习（在这种情况下需要付出一些努力——我想就像从自行车转向摩托车一样）。
尽管我不能强迫公司中的每个人立即切换——我真的没有打算。同样，git-svn通过“先试水”方法拯救了我们。但看到同事们的反应，切换可能会比任何人预期的早:)
我想说——即使我们忘记合并和提交，这些东西已经很适合作为只读前端用于查询、可视化、备份等等。
注意:
另一个出色的资源是Pro Git book，其中“切换活动分支”一节基本上说合并确实有效，但"不要向Subversion存储库dcommit Git合并提交。Subversion没有像Git那样处理合并，这会引起问题。这意味着您应该保持Git开发历史线性（即，没有从其他分支合并，只有变基）。"（http://learn.github.com/p/git-svn.html的最后一段）
dcommit只会存储合并内容，但历史记录将被破坏（这会破坏后续合并），因此您应该在合并后删除工作分支。无论如何，这毕竟是有道理的，在实践中很容易避免陷阱...在svn中，我发现人们通常不重新合并，因此如果您首先来自git世界，则可能只能看作是一步后退。--ignore-ancestry在那里给出了最好的结果。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 commit # am usually doing this in the git gui as well.. again, lightning fast.
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
git config diff.renamelimit 0 对你有用？ - inger现在有新的工具可用，可以解决git-svn的许多问题，并为使用Subversion和Git提供更好的体验。
除其他问题外，这些工具还可以解决一些分支和合并的问题。以下是概述：
git-svn
From the documentation:
CAVEATS
...
Running git merge or git pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.
There are primarily three reasons not to dcommit merge commits:
git-svn doesn't automatically send svn:mergeinfo property for merged branches. As result Subversion is not able to track those merges performed by git. This includes normal Git merges and cherry-picks.
as git-svn does not convert svn:ignore, svn:eol-style and other SVN properties automatically, merge commit does not have corresponding metadata in Git. As result, dcommit does not send these properties to SVN repository, so they get lost.
dcommit always sends changes to the branch referenced by a first parent of a merge commit. Sometimes changes appear where user doesn't expect them.
SubGit is a Git-SVN bi-directional server-side mirror.
If one has local access to Subversion repository, one can install SubGit into it:
$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify your branches and tags
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL
At this moment SubGit converts Subversion repository into Git (it works in opposite direction as well) and installs SVN and Git hooks. As result Subversion and Git repositories are synchronized: every commit and push starts hooks that convert incoming modifications immediately.
SubGit converts svn:ignore properties into .gitignore files, svn:eol-style and svn:mime-type properties to .gitattributes, so merge commits in Git retain this metadata.
When one pushes merge commit, SubGit converts all the new commits into Subversion revisions. It honors svn:mergeinfo property, so merge operation is properly tracked by SVN afterwards.
Even if user pushes very complex Git history, SubGit converts all the commits keeping the merge tracking data valid. We once pushed the whole history of git.git repository at once and it was properly converted into SVN.
SubGit is a commercial product. It is free for open-source and academic projects and also for projects with up to 10 committers.
For more details please refer to SubGit documentation and git-svn comparison page.
SmartGit is a client-side alternative for git-svn.
SmartGit also supports svn:ignore, svn:eol-style and svn:mime-type properties conversion. And it also sets svn:mergeinfo property for merge commits. It even updates necessary merge tracking data for cherry-pick commits.
SmartGit is a commercial Git and Mercurial client. It is free for non-commercial usage.
完全透露：我是SubGit开发人员之一。
我刚刚自己完成了这个。一种更简单的方法是传递git merge选项--squash，这将执行合并而不记录合并提交，使历史线性化以避免混淆git-svn。
我的合并也非常大，我必须设置git config diff.renamelimit 0，以便git可以正确找到所有重命名。
--no-ff合并选项似乎是为此而设计的：git merge --no-ff mybranch。 - Shadow Man