svn分支的GIT合并无法生成BASE文件
我从事的项目使用 svn 进行 CVS,大约 5-6 个月前,我们从主干分叉了分支 version_1_9_1。现在我必须合并它们。
为了减轻 svn 的负担,我想尝试 git 进行合并,所以我按照以下说明进行操作: http://blog.wuwon.id.au /2010/09/painless-merge-conflict-resolution-in.html
我最终使用以下命令:
git svn clone -s hxxp://svn/repo/project project (this takes avout 20min for +30k commmits)
git checkout -b version_1.9.1 remotes/version_1_9_1
git checkout -b the_trunk trunk
git merge version_1.9.1
但是当我执行“git mergetool”时,比如说文件 web.xml,meld 打开LOCAL 和 REMOTE 对话框,但缺少 BASE 文件。
当融合对话框仍然打开时,检查有哪些文件,并获取以下列表:
web.xml
web.xml.BACKUP.12480.xml
web.xml.LOCAL.12480.xml
web.xml.REMOTE.12480.xml
因此,据我了解,还应该有一个名为 web.xml.BASE.12480.xml 的文件,但它丢失了。
无论 diff3 激活还是停用,结果都是相同的。
这让我认为克隆有问题......所以我在干净的目录中执行了以下命令:(
git svn clone -s hxxp://svn/repo/project project
gitk
git checkout -b version_1.9.1 remotes/version_1_9_1
gitk
git checkout -b the_trunk trunk
gitk
顺便说一句。我在 ubuntu 11.04 上执行此操作)
每次运行 gitk 时,我都会看到平面“层次结构”,其中所有 svn提交是一个接着一个。所以如果我理解正确的话,“git svn clone”有问题,因为 git 找不到主干和分支 version_1.9.1 的共同祖先。
谁能指出我解决这个问题的正确方向?
感谢您的阅读。
I work on project which uses svn for CVS and about 5-6 months ago we forked branch version_1_9_1 from trunk. Now I have to merge them.
To ease my burden with svn, I wanted to try git for merging, so I followed instructions at:
http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html
I end up using following commands:
git svn clone -s hxxp://svn/repo/project project (this takes avout 20min for +30k commmits)
git checkout -b version_1.9.1 remotes/version_1_9_1
git checkout -b the_trunk trunk
git merge version_1.9.1
but when I do 'git mergetool' for, lets say file web.xml, meld opens dialogs for LOCAL and REMOTE, but BASE -file is missing.
While meld dialogs are still open, check which files there are, and get following list:
web.xml
web.xml.BACKUP.12480.xml
web.xml.LOCAL.12480.xml
web.xml.REMOTE.12480.xml
So, for my understanding there should be also file called web.xml.BASE.12480.xml, but its missing.
Result is same no matter if diff3 is activated or deactivated.
This lead me to think that there is something wrong with cloning... So I executed following commands in clean directory:
git svn clone -s hxxp://svn/repo/project project
gitk
git checkout -b version_1.9.1 remotes/version_1_9_1
gitk
git checkout -b the_trunk trunk
gitk
(Btw. Im doing this on ubuntu 11.04)
Each time I ran gitk, I see flat "hierarchy", where all svn commits are after another. So if I understand this correctly, there is something wrong with "git svn clone", as git cannot find common ancestor for trunk and branch version_1.9.1.
Can anyone point me to right direction with this issue?
Thanks for reading.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
问题出在 svn 分支上。它是从后备箱分叉出来的,因此它们之间没有任何联系。
为了检查我是否使用了:
merge-base 没有打印任何内容,这表明这两个分支没有关系。
我想有很多方法可以解决这个问题。由于我对 git 非常陌生,我无法找出任何巧妙的方法来利用 git 的潜力,所以我采用了一种蛮力的方式:
以下是执行上述 5 个步骤的命令:
总的来说,我对这次合并非常满意。花了一些时间才发现这两个分支没有相互连接,这导致 git merge 无法生成 .BASE 文件。生成假分支允许 git 生成 .BASE 文件,这使得合并变得更加容易:
更改的文件总数:390 个文件
没有假分支的合并冲突:220 个文件
与
与假分支的合并冲突:68 个文件
此外,在完成整个合并之后,我开始想知道没有假分支的合并是否可能 - 至少在某个合理的时间范围内。
感谢您的阅读。
Problem was with svn branch. It was forked from trunk so that there was no connection between them.
To check that I used:
merge-base didnt print anything, which tells that those two branches had no relation.
I guess there is many ways to fix this problem. Since Im very new with git, I couldn't figure out any clever way to use gits potential, so I went kind of brute force way:
Below are commands to do 5 steps above:
Over all, I was very happy with this merge. It took some time to figure out that those two branches were not connected to each other, which prevented git merge from producing .BASE file. Generating fake branch allowed git to produce .BASE file, which made merge much more easy:
Total files changed: 390 files
Merge conflicts without fake branch: 220 files
vs.
Merge conflicts with fake branch: 68 files
Also, after going throuhg whole merge, I started to wonder would merge without fake branch had even been possible - atleast in some reasonable time frame.
Thanks for reading.