Git Svn dcommit 错误 - 重新启动提交

Git Svn dcommit error - restart the commit

提问by Rob Wilkerson

Last week, I made a number of changes to my local branch before leaving town for the weekend. This morning I wanted to dcommit all of those changes to the company's Svn repository, but I get a merge conflict in one file:

上周，我在周末离开城镇之前对我当地的分支机构进行了一些更改。今天早上我想将所有这些更改提交到公司的 Svn 存储库，但是我在一个文件中遇到了合并冲突：

Merge conflict during commit: Your file or directory 'build.properties.sample' is probably out-of-date: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).

提交期间合并冲突：您的文件或目录“build.properties.sample”可能已过期：版本资源与事务中的资源不对应。要么请求的版本资源过期（需要更新），要么请求的版本资源比事务根更新（重启提交）。

I'm not sure exactly whyI'm getting this, but before attempting to dcommit, I did a git svn rebase. That "overwrote" my commits. To recover from that, I did a git reset --hard HEAD@{1}. Now my working copy seems to be where I expect it to be, but I have no idea how to get past the merge conflict; there's not actually any conflict to resolve that I can find.

我不确定为什么我会得到这个，但在尝试 dcommit 之前，我做了一个git svn rebase。那“覆盖”了我的承诺。为了从中恢复，我做了一个git reset --hard HEAD@{1}。现在我的工作副本似乎是我期望的地方，但我不知道如何解决合并冲突；实际上我找不到任何要解决的冲突。

Any thoughts would be appreciated.

任何想法将不胜感激。

EDIT:Just wanted to specify that I am working locally. I have a local branch for the trunk that references svn/trunk (the remote branch). All of my work was done on the local trunk:

编辑：只是想说明我在本地工作。我有一个引用 svn/trunk（远程分支）的主干的本地分支。我所有的工作都是在本地主干上完成的：

$ git branch
  maint-1.0.x
  master
  * trunk
$ git branch -r
  svn/maintenance/my-project-1.0.0
  svn/trunk

Similarly, git logcurrently shows 10 commits on my local trunk since the last commit with a Svn ID.

同样，自上次使用 Svn ID 提交以来，git log目前在我的本地主干上显示 10 次提交。

Hopefully that answers a few questions.

希望这能回答几个问题。

Thanks again.

再次感谢。

回答by sfossen

You should have created a local branch, and done the work on that, then when you get back, you update the master, rebase to the local branch, merge back to master then dcommit.

你应该已经创建了一个本地分支，并完成了它的工作，然后当你回来时，你更新 master，rebase 到本地分支，合并回 master 然后 dcommit。

So I'd try copying out the changes, to back them up.

所以我会尝试复制更改，以备份它们。

Create a local branch from the has svn sync point, merge your changes in there. Then back out the changes in the master branch, fetch, rebase to the branch, merge in from the local branch, fix any conflicts, then dcommit.

从 has svn 同步点创建一个本地分支，在那里合并您的更改。然后退出 master 分支中的更改，获取，rebase 到分支，从本地分支合并，修复任何冲突，然后 dcommit。

$ git checkout -b backup    # create a local backup branch with all your work
$ git checkout master   
$ git checkout -b backup2   # 2nd copy just to be safe
$ git checkout master
$ git reset --hard <this is the revision of the last svn-id> # clean up master to make the svn merge easier
$ git svn fetch    # this should update to the current version on the svn server
$ git rebase master backup  # may get a conflict here, fix and commit
... # after conflict is fixed and commited
$ git checkout master 
$ git merge backup --ff  # merge in your local commits
$ git svn dcommit        # push back to the svn

You can get additional info here

您可以在此处获取更多信息

Another answeryou might be interested in.

您可能感兴趣的另一个答案。

git-svn workflow articles

git-svn 工作流文章

Article

文章

回答by Rob Wilkerson

With much appreciation for VonC and sfassen's extraordinary patience with me, the solution sort of worked itself out. I don't know how or why, but maybe my initial rebase didn't work. To fix it I ended up rebasing again. From my local trunk branch:

非常感谢 VonC 和 sfassen 对我的非凡耐心，解决方案最终解决了。我不知道如何或为什么，但也许我最初的 rebase 不起作用。为了修复它，我最终再次变基。从我当地的主干分支：

$ git co -b backup  # backup the commits to my local trunk
$ git co trunk      # return to the local trunk
$ git svn rebase    # rebase the trunk from the Svn server
$ git br -d backup  # delete the backup branch

The key, of course, was that the rebase worked this time. I have no idea why it didn't work when I first did it, but I can't roll the clock back so I won't dwell on it.

当然，关键是这次 rebase 起作用了。我不知道为什么我第一次这样做时它不起作用，但我无法让时钟倒转，所以我不会详述它。

Thanks again for everyone's suggestions and patience with a newbie.

再次感谢大家的建议和对新手的耐心。

回答by VonC

To complete sfossen's excellent answer, here is some details:

为了完成sfossen的优秀回答，这里有一些细节：

With git-svn, you get by default a local branch named master. You should not do any work on it, only keep it up-to-date with the svn trunk branch with:

使用git-svn，默认情况下您会获得一个名为 master 的本地分支。你不应该对它做任何工作，只用 svn 主干分支让它保持最新：

• git svn fetchto get the history from the svn trunk branch on your local trunk branch: it will not apply those modifications on your working directory
• git checkout masterto switch on trunk branch (only if you were on another branch)
• git rebase trunkto synchronize master with trunk.

• git svn fetch从本地主干分支上的 svn 主干分支获取历史记录：它不会将这些修改应用于您的工作目录
• git checkout master打开主干分支（仅当您在另一个分支上时）
• git rebase trunk同步主干与中继。

However, all your modifications should be done on another local branch (lets call it local-devel).

但是，您的所有修改都应该在另一个本地分支上完成（我们称之为local-devel）。

• git branch local-devel
• git checkout local-devel

• git branch local-devel
• git checkout local-devel

If you have an urgent fix to do:

如果您有紧急修复要做：

• git checkout master: swith on master(),
• git svn fetch&& git rebase trunkto update it with svn trunk
• git branch fastfix && git checkout fastfix, branch it
• fix the bug, compile, test,
• git commit -a: local commit,
• git svn dcommitupdate the modification to the distant svn repo
• git checkout master && git rebase trunk: update master again
• git branch -D fastfix: remove hotfix branch
• git checkout local-devel && git rebase master: get back to dev, with the updated history done on master replayed on your dev branch

• git checkout master: 在 master() 上切换，
• git svn fetch&&git rebase trunk用 svn trunk 更新它
• git branch fastfix && git checkout fastfix, 分支它
• 修复错误，编译，测试，
• git commit -a：本地提交，
• git svn dcommit更新对远程 svn repo 的修改
• git checkout master && git rebase trunk: 再次更新主
• git branch -D fastfix: 删除修补程序分支
• git checkout local-devel && git rebase master: 回到 dev，在 master 上完成的更新历史记录在你的 dev 分支上重播

It is a bit of an hassle at first, but way more comfortable than an svn diffin a file to be applied later.

起初有点麻烦，但比svn diff以后应用的文件更舒服。

回答by abbot

I had a similar situation. I was doing an git svn dcommitover a bad network connection and it failed at some point. I've discovered that the problem was caused by the fact that Subversion repository already had a new commit, but local git-svn counterpart considered that a commit was not in SVN yet. Solutions from other answers here did not help, however this did:

我也有类似的情况。我git svn dcommit在一个糟糕的网络连接上做了一个，它在某个时候失败了。我发现这个问题是由于 Subversion 存储库已经有一个新的提交，但是本地 git-svn 对应版本认为提交还没有在 SVN 中。此处其他答案的解决方案没有帮助，但是这样做了：

git svn reset -r <last_svn_commit_git_was_aware_of>
git svn fetch
git svn rebase

After this I was finally able to do git svn dcommitwithout any errors.

在此之后，我终于能够做到git svn dcommit没有任何错误。

回答by wildintellect

Several places I've read that it is bad practice when using git svn to use a separate branch. Something pertaining to git commits not showing up in svn the way you would expect.

我在几个地方读到过，使用 git svn 使用单独的分支是不好的做法。与 git commit 相关的东西没有像你期望的那样出现在 svn 中。

The following answer from http://progit.org/book/ch8-1.htmlappears to be the cleanest way:

来自http://progit.org/book/ch8-1.html的以下答案似乎是最干净的方法：

git svn rebase
git svn dcommit

I also tried the most popular option above but it didn't always work for me, as the git rebase doens't roll back the to match the svn upstream but just back to last git commit.

我也尝试了上面最流行的选项，但它并不总是对我有用，因为 git rebase 不会回滚以匹配上游的 svn 而只是回滚到最后的 git 提交。

回答by Ryan Graham

I was going to comment, but thought this deserved more visibility...

我打算发表评论，但认为这值得更多的关注......

git svn rebaseis supposedto re-write your commits. From the description and comments, I get the impression that after you rebased, you forced your old commits back on top. The commits have to be replaced with newer versions that don't conflict.

git svn rebase是应该重新写你的提交。从描述和评论中，我得到的印象是，在您重新定位后，您迫使旧的提交重新回到顶部。必须用不冲突的较新版本替换提交。

To avoid having to dig through the reflog, you might want to get in the habit of making a quick tag before doing your git svn dcommit. After the dcommit succeeds, delete the tag. If the tag fails, you can do a git reset --hardfollowed by a git merge <tag>. Re-run your rebase to get your history back in order, re-tag and re-dcommit again.

为避免翻阅 reflog，您可能需要养成在执行git svn dcommit. dcommit 成功后，删除标签。如果标记失败，您可以执行 agit reset --hard后跟 a git merge <tag>。重新运行您的 rebase 以恢复您的历史记录，重新标记并再次重新提交。