简体   繁体   English

git svn dcommit在分支上失败

[英]`git svn dcommit` failing on a branch

I have been using git-svn to communicate with my company's svn repo for a while now without any major headaches. 我一直在使用git-svn与公司的svn存储库通信一段时间了,没有任何大的麻烦。

Today, the “headache”-part changed dramatically: 今天,“头痛”部分发生了巨大变化:
I've been working on master/trunk pretty exclusively, and needed to merge most (but not all!) of those change-sets into a new svn-branch, that originated from a pre-existing svn-branch. 我一直在专门处理master/trunk ,需要将大多数(但不是全部!)这些变更集合并到一个新的svn分支中,该分支来自一个先前存在的svn分支。

Basically this: 基本上是这样的:

🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  master/trunk
 \
  \
   2🍒--2🍒--2🍒--2🍒--2🍒                                        versioned-release

Should have become this: 应该变成这样的:

🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  master/trunk
 \
  \
   2🍒--2🍒--2🍒--2🍒--2🍒                                        versioned-release
                         \
                          \
                           1🍒--1🍒--1🍒--1🍒--1🍒--1🍒           new-versioned-release

Where 💩 are commits that shouldn't be in the new-versioned-release , and x🍒 the wanted commits from the respective branches x . 其中💩是不应在new-versioned-release的提交,而x🍒是来自各个分支x的所需提交。

So I did the following: 所以我做了以下事情:

  1. git checkout -b versioned-release-svn remotes/versioned-release
  2. git svn branch new-versioned-release -m "Preparing for merge of XXX"
  3. git checkout -b new-versioned-release-svn remotes/new-versioned-release
  4. git cherry-pick ... for every 1🍒 , resolving any conflicts on the way. git cherry-pick ...1🍒 ,解决了途中的任何冲突。

Because I wanted to be sure I was really going to target the correct branch on the repo, I then ran git svn dcommit --dry-run which did not yield any errors or warnings, but told me… 因为我想确定自己真的要针对回购协议上的正确分支,所以我运行了git svn dcommit --dry-run ,它没有产生任何错误或警告,但告诉我…

Committing to svn://username@$repo-host/$repo-name/$path/branches/new-versioned-release ...

…followed by a couple of diff-tree lines. ……接着是几条diff-tree线。

So I attempted to omit the --dry-run and half way through the commits ended up with… 因此,我尝试省略--dry-run并在提交的一半途中最终导致…

Item already exists in filesystem: File already exists: filesystem '/data/subvroot/$repo-name/db', transaction '20856-g3m', path '/$path/branches/new-versioned-release/some-directory' at /usr/libexec/git-core/git-svn line 862

…and a bunch of unstaged changes. ......和一堆不分级的变化。

Apart from the obvious — “WTF?!?” and “How do I get out of this mess without losing everything I did?” — I have two questions: 除了显而易见的“ WTF?!?”和“如何在不失去所做的一切的情况下摆脱困境”之外,我还有两个问题:

  1. Assuming I was back to before git svn dcommit : How do I get my local branch dcommit to its planned destination? 假设我回到git svn dcommit之前:如何将本地分支dcommit到达其计划的目的地?
  2. By now it seems obvious, that this wasn't the right way to achieve what I wanted…but how should I have done it, instead? 现在看来,这显然不是实现我想要的目标的正确方法……但是应该怎么做呢?

Everything I found for the error-message, that somehow resembled my situation, so far was this other stack overflow question and the proposed solution of “somehow […] to blow away the .git/svn metadata directory” doesn't resonate quite that well with me… 我为错误消息找到的所有内容都在某种程度上类似于我的情况,到目前为止, 这是另一个堆栈溢出问题 ,并且建议的解决方案“以某种方式[...] .git/svn元数据目录”并没有引起共鸣我很好...

Someone just up–voted my old question, so I thought I'd share how I do that nowadays. 有人刚刚投票赞成我的老问题,所以我想我现在应该分享我的做法。

It works really quite well. 它真的很好。

Assuming the git repository has been created using 假设已经使用以下命令创建了git存储库

git svn clone \
    --prefix svn/ \
    --stdlayout \
    svn://username@$repo-host/$repo-name/$path
    $git_repo_name

change into the git repo, and there run 更改为git repo,然后运行

git checkout svn/versioned-release
git svn branch new-versioned-release

This will result in the following history on the SVN server: 这将在SVN服务器上产生以下历史记录:

🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  trunk
 \
  \
   2🍒--2🍒--2🍒--2🍒--2🍒                                        versioned-release
                          \
                           \
                            3⭐️                                    new-versioned-release

Now I'd run 现在我要跑步

git checkout svn/new-versioned-release
git checkout -b new-versioned-release

# resulting in the following **local** history:
#
# 🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  master (tracks 'svn/trunk')
#  \
#   \
#    2🍒--2🍒--2🍒--2🍒--2🍒--3⭐️                         new-versioned-release (tracks 'svn/new-versioned-release')

This is the foundation for achieving what I wanted. 这是实现我想要的基础。

There is one additional commit, because branching in SVN doesn't work the same way as in Git: creating a branch always means a new revision, (aka commit) and that's where the 3⭐️ comes from. 还有一个额外的提交,因为SVN中的分支与Git中的工作方式不同:创建分支始终意味着一个新的修订版(又名提交),这就是3⭐️来源。 It doesn't really matter, but it's there. 并不重要,但是就在那里。

I can now git cherry-pick all the 1🍒 s, ending up with this local history: 现在,我可以git cherry-pick所有1🍒 git cherry-pick 1🍒 ,最后显示以下本地历史记录:

🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  master (tracks 'svn/trunk')
 \
  \
   2🍒--2🍒--2🍒--2🍒--2🍒--3⭐️--1🍒--1🍒--1🍒--1🍒--1🍒--1🍒  new-versioned-release (tracks 'svn/new-versioned-release')

When I now git svn dcommit while sitting on new-versioned-release in git, the history on the SVN server looks like what I wanted to end up with: 现在,当我坐在git svn dcommit new-versioned-release git svn dcommit new-versioned-release上时git svn dcommit时,SVN服务器上的历史记录看起来像是我想要的最终结果:

🍒---💩---💩---💩--1🍒--1🍒---💩--1🍒---💩---💩--1🍒--1🍒--1🍒---💩  trunk
 \
  \
   2🍒--2🍒--2🍒--2🍒--2🍒                                        versioned-release
                          \
                           \
                            3⭐️--1🍒--1🍒--1🍒--1🍒--1🍒--1🍒    new-versioned-release

The only difference being that additional 3⭐️ from creating the third SVN branch. 唯一的区别是,从创建第三个SVN分支中获得了额外的3⭐️

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM