使用git-svn(或类似的)*只是*来帮助svn合并? [英] Using git-svn (or similar) *just* to help out with an svn merge?

问题描述

我的项目中出现了一些复杂的Subversion合并:已经分裂了很长时间的大型分支. Svn产生了太多冲突-有些冲突似乎是虚假的.

Some complex subversion merges are coming up in my project: big branches that have been apart for a long time. Svn gives too many conflicts - and some of them seem spurious.

鉴于git因出色的合并体验而受到赞誉， git-svn 仅出于使合并更易于管理的好处有什么好处?

Given that git is praised for a superiour merge experience, Would it be any good to use git-svn just for the benefit of making the merge more manageable?

您能推荐其他替代方法(例如svk，hgsvn)来减轻合并的痛苦吗?

Can you recommend other alternatives (eg. svk, hgsvn) to lessen the merge pain?

有些冲突很容易解决(例如java导入，空格)-所以我也想知道是否有针对这些冲突的自动化解决方案.

Some conflicts are easy enough to resolve (e.g java imports, whitespaces) - so I'm also wondering if there is any automated solutions for those.

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

A full switch to DVCS might happen in the future (some of us would love that), but not right now. (UPDATE: this isn't true any longer - the team switched fully recently and are happy about it).

谢谢.

PS:有些帖子似乎相关(例如， git-svn合并2个svn分支机构)，但它们并未完全回答这个问题.

PS: there are posts that seem to be related (eg. git-svn merge 2 svn branches) but they don't fully answer this question.

更新:沿着这条路上(往上走)后，请参阅我的-novice-答案.

Update: see my -novice- answer after going down (and up:) this road.

推荐答案

尝试回答我的问题:将git用于svn合并似乎很有希望.

Trying to answer my question: using git for svn merges seems promising.

更新:这不仅是有希望的，而且是巨大的成功.简而言之， Linus是正确的.

Update: it's not just promising, it's a great success. In short, Linus was right.

刚刚完成了两个相距1.5年的svn分支的大规模合并； 3k文件被更改，在svn中产生了大量冲突(我认为约为800).

Just completed a huge merge of 2 svn branches that have been apart for 1.5 years; 3k files were changed, got tons of conflicts in svn (~800 I think).

我发现git& git-svn拯救生命:

I found git & git-svn a life saver:

• 自动冲突解决:首先，它减少了很多冲突文件(我认为是一半)
• 令人难以置信的表现
• 出色的回购/分支模型，灵活的工作流程:轻松进行各种实验诸如逐块(按时间)合并的方法，总是进行健全性检查(编译等)；每当遇到麻烦时:只需回溯即可.您总是可以在需要时退后一步.
• 可用性，出色的工具:
  • git-log(以及基础的git-rev-parse选项)，没有比这更强大的功能了.也很方便:-p一口气给您带来差异.在svn中，您会得到一个日志，然后找到该修订版1:修订版"的差异，或使用笨拙的UI.查找何时在存储库中添加/删除字符串，同时搜索多个分支
  • gitk:结合强大的搜索功能，对于可视化分支历史非常有用.在其他工具中还没有看到这样的东西，尤其是没有它那么快.没关系，它在Tk中，真是太好了
  • git gui:即使不是最性感的也可以正常工作-对新手发现事物有很大帮助
  • blame:一个奇迹.是的，它可以检测出原始句段的来源(复制和粘贴等)
  • mergetool:比启动大型svn merge每次遇到冲突时都停下来(即每5分钟)，按'(p)ostpone'，要好得多，比手动搜寻有冲突的文件要愉快得多之后.希望将其整合到git gui中(为此需要一个微小的补丁). 发现集成外部差异工具比svn更好地配置.
  • 可插拔合并驱动程序及其精细控制
  • rebase允许过滤出svn历史记录中较混乱的部分
  • auto-conflict resolution: for a start, it gave a lot less conflicted files (~half I think)
  • unbelievable performance
  • excellent repo/branching model, flexible workflows: easy experimentation with various approaches, such as chunk-by-chunk(in time) merge, always doing sanity checks(compile,etc); whenever trouble hits: just backtrack. You can always just take a step back when needed.
  • usability, great tooling:
    • git-log (and the underlying git-rev-parse options), nothing can be more powerful than this. It's handy as well: -p gives you diffs in one go; in svn you get a log, then find the diff for that "revision-1:revision", or use clumsy UIs. Find when a string was added/removed into the repo, search multiple branches simultaneously
    • gitk: hugely useful for visualising branch histories, combined with great search capabilities. Haven't seen anything like this in other tools, especially not as fast as this. Nevermind it's in Tk, it's just brilliant
    • git gui: works fine even if not the sexiest - great help for the novice to discover things
    • blame: a miracle. Yes, it detects where the original segment comes from (copy&paste etc)
    • mergetool: much more pleasant experience than kicking off the big svn merge which then stops everytime (ie. every 5 minutes) it runs into a conflict, press '(p)ostpone', than manually hunt for conflicted files later. Preferred a flavour of this integrated in git gui (needed a tiny patch for that). Found integrating external diff tools better configurable than in svn.
    • pluggable merge drivers and fine grained control of them
    • rebase allowed to filter out messier parts of the svn history
    • 具有 Unison 的USB驱动器使同步工作<->回家了蛋糕
    • 如果没有git的疯狂压缩(这是一个5年历史的项目，具有26k提交，大量分支和二进制文件，trunk svn签出:1.9Gb =>，这是不可能实现的)全部在git repo:1.4Gb中！ )
    • a USB drive with Unison made syncing work<->home a piece of cake
    • this wouldn't have been possible without git's crazy compression (5 years old project with 26k commits, tons of branches and binary files, trunk svn checkout: 1.9Gb => all of these in the full git repo: 1.4Gb!)

    因此，这确实可以使噩梦变成欢乐-尤其是如果您喜欢学习(在这种情况下确实需要付出一些努力-我想就像在骑自行车之后学习摩托车一样).

    So, this really can make the difference from a nightmare to joy - especially if you enjoy learning (which does take some effort in this case - I guess like learning a motorbike after a bicycle).

    即使我不能强迫公司中的每个人都立即更换-我确实并没有打算这样做.再次，git-svn通过先浸入脚趾"的方法为我们节省了费用.但是看到同事的反应，转换的发生可能比预期的要早得多:)

    Even though I can't force everyone in the company to switch immediately - I really didn't intend to actually. Again, git-svn saves us by 'dipping the toe first' approach.. But seeing colleagues' reactions the switch might happen much before anyone expected:)

    我会说-即使我们忘记合并&提交，这些东西已经很好地用作查询，可视化，备份等的只读前端.

    I'd say- even if we forget about merges & commits, this stuff is already great as a read-only frontend for queries, visualisation, backups, etc..

    注意事项:

    不取消提交Git合并提交到 Subversion存储库.颠覆 不能以相同的方式处理合并 作为Git，这会引起问题. 这意味着您应该保持Git 发展历史是线性的(即，否 从其他分支合并而来 重新定级". ( http://learn.github.com/p/git-svn.html的最后一段)

    "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书，基本上是切换活动分支"部分表示合并确实可以，但是dcommit仅存储合并的内容，但是历史记录将受到影响(这会破坏后续的合并)，因此您应在合并后删除工作分支. 无论如何，毕竟这是有道理的，并且在实践中很容易避免在这里出现陷阱..在svn中，我发现人们通常无论如何都不会重新合并，因此，只有当您最初来自git world时，这才可以视为退后一步地方.

    Another excellent source is the Pro Git book, section 'Switching Active Branches' basically says that the merge does work, but dcommit will only store the content of the merge, but the history will be compromised (which breaks subsequent merges), so you should drop the work branch after merge. Anyway it makes sense after all, and in practice it's easy to avoid traps here.. in svn, I found people do not usually re-merge anyway so this could only be seen as a step back if you come from git world in the first place.

    无论如何，dcommit只是为我工作.我在我自己的svn工作分支上进行了此操作，仅为此而保留，因此避免了那段时间的任何额外冲突.但是，我决定从该工作分支到svn中的svn干线进行最终合并(在git中同步所有内容之后)； --ignore-ancestry在这里给出了最好的结果.

    Anyhow, the dcommit just worked for me. I did it onto my own svn workbranch that I kept for this only, so avoided any extra conflicts that time. However, I decided to do the final merge from this workbranch to the svn trunk in svn (after syncing up everything in git); --ignore-ancestry gave the best results there.

    更新:正如我稍后发现的那样，只需将您要退出的分支保持线性即可轻松避免上面的最后几步(额外的svn分支和merge-ignore-ancestry).就像Gabe在下面说的那样，merge --squash只是创建了一个简单的愚蠢的svn友好提交.刚准备好在本地分支机构进行大规模合并(可能需要数天/周)时，我现在就可以:

    Update: as I found out later, the last few steps above (extra svn branch and merge--ignore-ancestry) is easily avoided by just keeping the branch you're dcomitting from linear. As Gabe says below, merge --squash just creates a simple stupid svn-friendly commit. Just when ready with huge merge(s) on the my local branch (which might take days/weeks), I would now just:

    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端开始，合并跟踪将无法正常工作，直到我们完全切换为止.我等不及了.

    I know the merge tracking won't work great from the svn-side, until we switch fully. I can't wait for that.

    更新:@Kevin请求了有关合并svn分支的整个过程的更多细节.无论如何，这些天我的方式(当然，在合并后仍坚持使用git-svn；就像一些新感染的同事一样.)

    UPDATE: @Kevin requested some more details on the whole process of merging svn branches.. There are lots articles, posts out there, but as a novice I found some of the confusing/misleading/out of date.. Anyhow, the way I do it these days (of course, stuck with git-svn after that merge affair; just as some newly infected colleagues)..

    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的内置mergetool集成(在发生冲突的文件上单击鼠标右键).不过，这略有限制，因此请参见上面的我的小补丁，该插件可让您插入Shell脚本，在其中可以调用您喜欢的任何mergetools(我有时尝试并行操作多种多样的合并工具，因为它们引起了令人惊讶的悲伤.我被kdiff3卡住了.

    Actually I preferred to use 'git gui's builtin mergetool integration (right click on file in conflict). That's slightly limited though,so see my little patch above, which allows you to plugin a shell script where you can invoke whatever mergetools you prefer (I tried a variety of them sometimes in parallel as they caused a surprising amount of grief.. but normally I'm stuck with kdiff3..

    合并步骤顺利进行时(无冲突)，将自动完成合并提交；否则，您可以解决冲突

    When a merge step goes fine (no conflict), a merge commit is done automatically; otherwise, you resolve conflicts then

    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端..但是在这种情况下，还可以.

    The last phase.. Note that so far we had only local commits, not talking to the svn server yet. Unless you've used --squash or other tricks, you now end up with a graph where your merge commit has 2 parents: the tips of your svn-mirror branches. Now this is the usual gotcha: svn can only take linear history.. so 'git-svn' simplifies it by just dropping the second parent (svn-branch-to-merge in the above case).. so the real merge tracking is gone on the svn side..but otherwise it's fine in this case.

    如果您想要一种更安全/更清洁的方式，这就是我之前的代码段出现的地方:只需使用--squash进行最终合并即可.使较早的版本适应此流程:

    If you want a safer/cleaner way, this is where my earlier snippet comes in: just do the final merge with --squash. Adapted the earlier one to this flow:

    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
    

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

    oops, this is getting way too long, stopping before too late.. Good luck.

    这篇关于使用git-svn(或类似的)*只是*来帮助svn合并?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！