svn分支的GIT合并无法生成BASE文件

发布于 2024-11-28 20:50:46 字数 1287 浏览 0 评论 0原文

我从事的项目使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟雨扶苏 2024-12-05 20:50:46

问题出在 svn 分支上。它是从后备箱分叉出来的,因此它们之间没有任何联系。

为了检查我是否使用了:

$ git svn clone -s hxxp://svn/repo/project project
$ git checkout -b the_trunk remotes/trunk
$ git checkout -b version_1.9.1 remotes/version_1_9_1
$ git branch
   master
   the_trunk
   version_1.9.1
$ git merge-base the_trunk version_1.9.1

merge-base 没有打印任何内容,这表明这两个分支没有关系。

我想有很多方法可以解决这个问题。由于我对 git 非常陌生,我无法找出任何巧妙的方法来利用 git 的潜力,所以我采用了一种蛮力的方式:

  1. 我在主干中搜索了 version_1_9_1 分叉的最后一次提交。
  2. 从那时起创建了新的 git 分支,
  3. 用 version_1_9_1 内容替换了这个新分支中的所有内容,
  4. 将其合并到主干,
  5. 并享受合并冲突的乐趣(说真的,这比 svn 提供的要容易得多)。

以下是执行上述 5 个步骤的命令:

$ gitk <= to find git revision id of forked commit, lets say its 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout the_trunk
$ git branch fake_version_1.9.1 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout version_1.9.1
$ mkdir ../temp
$ cp -r projectfiles ../temp     <= remember not to copy .git directory
$ git checkout fake_version_1.9.1
$ rm -r projectfiles
$ cp -r ../temp/* .
$ git commit -a
$ git checkout the_trunk
$ git merge fake_version_1.9.1
$ git mergetool     <= google "git mergetool" for instruction to setup tool for conflicts, I used p4merge
$ git commit -a
$ git svn dcommit

总的来说,我对这次合并非常满意。花了一些时间才发现这两个分支没有相互连接,这导致 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:

$ git svn clone -s hxxp://svn/repo/project project
$ git checkout -b the_trunk remotes/trunk
$ git checkout -b version_1.9.1 remotes/version_1_9_1
$ git branch
   master
   the_trunk
   version_1.9.1
$ git merge-base the_trunk version_1.9.1

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:

  1. I searched last commit in trunk from where version_1_9_1 was forked.
  2. created new git branch from that point
  3. replaced all content from this fresh branch with version_1_9_1 contents
  4. merged it to trunk
  5. had fun with merge conflicts (seriously, it was so much more easy than what svn would have offered).

Below are commands to do 5 steps above:

$ gitk <= to find git revision id of forked commit, lets say its 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout the_trunk
$ git branch fake_version_1.9.1 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout version_1.9.1
$ mkdir ../temp
$ cp -r projectfiles ../temp     <= remember not to copy .git directory
$ git checkout fake_version_1.9.1
$ rm -r projectfiles
$ cp -r ../temp/* .
$ git commit -a
$ git checkout the_trunk
$ git merge fake_version_1.9.1
$ git mergetool     <= google "git mergetool" for instruction to setup tool for conflicts, I used p4merge
$ git commit -a
$ git svn dcommit

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文