使用git svn（或类似）*只是*来帮助svn合并？_Svn_Merge_Git Svn_Hgsubversion_Svk

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

svn merge

使用git svn（或类似）*只是*来帮助svn合并？,svn,merge,git-svn,hgsubversion,svk,Svn,Merge,Git Svn,Hgsubversion,Svk,我的项目中出现了一些复杂的subversion合并：分离了很长时间的大分支。Svn给出了太多的冲突，其中一些似乎是虚假的鉴于git因其卓越的合并体验而备受赞誉，仅仅为了使合并更易于管理，使用git svn有什么好处吗您能否推荐其他替代方案（例如svk，hgsvn）来减轻合并的痛苦有些冲突很容易解决（例如java导入、空白），所以我还想知道是否有自动解决这些冲突的方法完全转向DVCS可能在未来发生（我们中的一些人会喜欢），但不是现在。（最新消息：这不再是真的了——团队最近完全转换了，

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

鉴于

git

因其卓越的合并体验而备受赞誉，仅仅为了使合并更易于管理，使用

git svn

有什么好处吗

您能否推荐其他替代方案（例如

svk

，

hgsvn

）来减轻合并的痛苦

有些冲突很容易解决（例如java导入、空白），所以我还想知道是否有自动解决这些冲突的方法

完全转向DVCS可能在未来发生（我们中的一些人会喜欢），但不是现在。（最新消息：这不再是真的了——团队最近完全转换了，并且对此感到高兴）

提前谢谢

附言：有些帖子似乎是相关的，但它们并没有完全回答这个问题

更新：沿着这条路往下走（和往上走：）后，请看我的-新手-答案。

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

更新：这不仅仅是一个有前途的计划，也是一个巨大的成功。简言之

刚刚完成了两个svn分支机构的大规模合并，这两个分支机构已经分离了1.5年；3k文件被更改，svn中出现了大量冲突（我想大约800个）

我发现git&git svn是一个救生员：

自动冲突解决：首先，它提供的冲突文件要少得多（我想大约有一半）
难以置信的表演
优秀、灵活的工作流程：轻松尝试各种方法，例如逐块（及时）合并，始终执行健全性检查（编译等）；无论何时遇到麻烦，只要回过头来。当需要的时候，你总是可以后退一步
可用性、出色的工具：
- ```
git log
```
  （以及底层的
```
git rev parse
```
  选项），没有什么比这更强大的了。它也很方便：
```
-p
```
  一次完成差分；在svn中，您会得到一个日志，然后找到“修订版1：修订版”的差异，或者使用笨拙的UI。查找在回购中添加/删除字符串时，同时搜索多个分支
- ```
gitk
```
  ：与强大的搜索功能相结合，对可视化分支历史非常有用。在其他工具中没有见过类似的情况，尤其是没有这么快。不管它在Tk里，它太棒了
- ```
git-gui
```
  ：即使不是最性感的，也可以很好地工作-对新手发现事物有很大帮助
- ```
责备
```
  ：一个奇迹。是，它检测原始段的来源（复制和粘贴等）
- ```
mergetool
```
  ：比启动大型的
```
svn merge
```
  更愉快的体验，每次（即每5分钟）遇到冲突时，按下“（p）ostpone”，而不是以后手动查找冲突文件。首选集成在
```
git gui
```
  中的这一风格（需要一个）。发现集成外部差异工具比在
```
svn
```
  中配置更好
- 可插入合并驱动程序及其细粒度控制
- ```
rebase
```
  允许筛选出svn历史中更混乱的部分
分发：工作时无需到办公室，可在火车/飞机等上暂停并逐步前进。。
- 一个带同步功能的USB驱动器让工作间变得轻而易举
- 如果没有git的疯狂压缩，这是不可能的（5年的项目，有26k个提交，大量的分支和二进制文件，trunk svn checkout:1.9Gb=>所有这些都在完整的git repo:1.4Gb中！）

所以，这真的可以让你从噩梦变为快乐——特别是如果你喜欢学习的话（在这种情况下确实需要一些努力——我想就像先学一辆摩托车，再学一辆自行车）

尽管我不能强迫公司里的每个人立即换工作，但我真的不打算这么做。同样地，

git svn

通过“先发制人”的方法拯救了我们。。但看到同事们的反应，这种转变可能比任何人预期的要早得多：）

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

警告：

“不提交Git合并提交到 Subversion存储库。Subversion 不以相同的方式处理合并作为Git，这将导致问题。这意味着你应该保留你的Git 发展历史线性（即，无从其他分支合并，只是重定基期）。” （草案最后一段）

另一个很好的来源是“切换活动分支”部分，该部分基本上说合并确实有效，但是

dcommit

将只存储合并的内容，但是历史记录将被破坏（这会破坏后续合并），因此您应该在合并后删除工作分支。不管怎样，这毕竟是有道理的，而且在实践中，在这里很容易避免陷阱。。在svn中，我发现人们通常不会重新合并，因此，如果你最初来自git世界，这只能被视为一种退步

不管怎么说，dcommit只是为我工作。我在我自己的svn工作分支上做了这件事，我只保留了这个分支，所以避免了那个时候的任何额外冲突。然而，我决定在svn中完成从这个工作分支到svn主干的最后合并（在git中同步所有内容之后）<代码>--忽略祖先在那里给出了最好的结果

更新：正如我后来发现的那样，上面的最后几个步骤（额外的svn分支和合并——忽略祖先）很容易避免，只需保持您正在提交的分支的线性。正如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

我知道合并跟踪

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

$ 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