22

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

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

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

任何想法将不胜感激。

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

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

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

希望这能回答几个问题。

再次感谢。

4

6 回答 6

39

你应该已经创建了一个本地分支，并完成了工作，然后当你回来时，你更新 master，rebase 到本地分支，合并回 master 然后 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

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

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

git-svn 工作流文章

文章

于 2009-03-10T06:00:20.460 回答
12

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

$ 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

当然，关键是这次变基起作用了。我不知道为什么当我第一次这样做时它不起作用，但我不能让时钟倒退，所以我不会纠缠于此。

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

于 2009-03-10T13:30:51.347 回答
5

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

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

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

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

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

如果您有紧急修复工作要做：

  • 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: 再次更新master
  • git branch -D fastfix：删除修补程序分支
  • git checkout local-devel && git rebase master: 回到 dev，在 master 上完成的更新历史在你的 dev 分支上重播

一开始有点麻烦，但比svn diff在稍后应用的文件中要舒服得多。

于 2009-03-10T06:41:12.143 回答
4

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

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

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

于 2010-06-12T18:56:49.930 回答
3

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

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

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

于 2009-03-10T15:52:02.490 回答
3

我在几个地方读到，使用 git svn 使用单独的分支是不好的做法。与 git 提交有关的东西没有像您期望的那样显示在 svn 中。

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

git svn rebase
git svn dcommit

我也尝试了上面最受欢迎的选项，但它并不总是对我有用，因为 git rebase 不会回滚以匹配上游的 svn，而只是回到最后一个 git commit。

于 2011-07-07T21:10:00.950 回答