gpt4 book ai didi

git - SVN 主干被旧版本覆盖。项目和主干文件夹现在有不同的历史

转载 作者:太空狗 更新时间:2023-10-29 14:06:30 25 4
gpt4 key购买 nike

背景

我们有一个包含多个项目的 SVN 存储库:

ROOT
- Project1
- trunk
- Project2
- trunk

..等等

然后我们开始迁移到 git。我们设置 subgit 以保持 SVN 和 GIT 存储库同步(双向)。几个月来,我们有一些开发人员使用 svn,一些使用 git,显然没有任何问题。

上面的每个项目都变成了一个git仓库,subgit配置为:

trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*

到目前为止一切顺利。让我们从现在开始关注Project1

问题

我注意到最近在 svn 中完成的一些提交没有移植到 git。查看 svn 端的日志,我发现这些提交在 svn 中也处于“不一致”状态(日志部分匿名):

$ svn log -v Project1

------------------------------------------------------------------------
r6109 | user1 | 2015-01-13 12:47:43 +0100 (di, 13 jan 2015) | 1 line
Changed paths:
R /Project1/trunk (from /Project1/trunk:5477)

Branch '/trunk' replaced from /trunk:5477
------------------------------------------------------------------------
r6089 | user2 | 2015-01-08 13:46:27 +0100 (do, 08 jan 2015) | 1 line
Changed paths:
M /Project1/trunk/src/com/....

-- fix xyz
------------------------------------------------------------------------
r5978 | user2 | 2014-12-26 21:30:28 +0100 (vr, 26 dec 2014) | 4 lines
Changed paths:
M /Project1/trunk/src/com/...
-- fix abc
------------------------------------------------------------------------
[ ... more commits ... ]
------------------------------------------------------------------------
r5477 | user2 | 2014-10-16 17:07:25 +0200 (do, 16 okt 2014) | 1 line
Changed paths:
M /Project1/trunk/src/com/...
-- fix bug23

现在,最后一个commit r6109 看起来很可怕。好像说当前trunk已经被r5477覆盖了。

确实,trunk 文件夹的日志完全错过了中间的修订:

$ svn log -v Project1/trunk

------------------------------------------------------------------------
r6109 | user1 | 2015-01-13 12:47:43 +0100 (di, 13 jan 2015) | 1 line
Changed paths:
R /Project1/trunk (from /Project1/trunk:5477)

Branch '/trunk' replaced from /trunk:5477
------------------------------------------------------------------------
r5477 | user2 | 2014-10-16 17:07:25 +0200 (do, 16 okt 2014) | 1 line
Changed paths:
M /Project1/trunk/src/com/...
-- fix bug23

问题

我需要一些帮助来确定当前状态和可能的解决方案。

我认为发生了什么(请在这里帮助我!):

  • 在某些时候,在同一源上使用 git 的开发人员使用 git reset --hard 将工作副本重置为本地 master 分支,该分支位于与 svn r5477 对应的提交处,并将其推送给远程主机。
  • 这由 subgit 翻译,产生了 svn 修订版 6109,其中写着“Branch '/trunk' replaced from/trunk:5477”
  • 因为git仓库映射到Project1/trunk,这里已经用r5477重写
  • 然而,文件夹 Project1 甚至没有被 subgit 看到,这解释了为什么 Project1 的历史仍然包含现在丢失的提交的日志(trunk 中的代码实际上回到了 r5477 修订版)。

谁能确认这可能是当前状态?我还在忽略什么吗?我不知道 svn 可以让你(在这种情况下是 subgit)以不一致的历史结束。

如果这是真的,谁能建议最好的解决方案是什么?请注意,git 存储库没有那部分历史记录,因为它只同步 Project1/trunk 而不是 Project1。我觉得这应该在 svn 存储库中修复。但我不知道怎么办。

以下是可能的解决方案吗?

$ cd Project1
$ svn merge -rHEAD:6089 .
$ svn ci

任何人的警告和/或更好的建议?

最佳答案

我会解释发生了什么Non-fast-forward update translation

Git 仓库中有一个'master' 的更新,它绑定(bind)到SVN 中的trunk。此外,更新是非快进的,默认情况下,如果没有 git push 命令的 -f 选项,Git 不允许这样的推送。非快进更新被转换为分支替换,因为这是 SVN 存储库中最接近的模拟。例如,您可以在这样之后比较 git log master 并更新相应的 svn log -v Project1/trunk 输出,看到两者都不包含 r6089,并且第一次提交列出的将是 r5477(如果我们不考虑 r6109 没有任何变化,在 Git 中没有模拟)。要在 git log 输出中查看修订号,您可以按照 SubGit book 的“4.6. 推荐的客户端 Git 配置”部分中描述的方式配置 Git 客户端。并运行 git fetch。所以我不认为 SVN 和 Git 存储库不一致。

如果你想防止将来分支替换,你不应该使用git push -f命令。如果您想严格禁止此类更新,您可以将服务器上 Git 配置的 receive.denyNonFastForwards 选项设置为 true

关于修复:有两种方法。如果您可以在您的 Subversion 历史记录中进行这样的提交,您可以再次替换您的 trunk 但来自 trunk@6089。您可以从 SVN 端执行此操作,例如分两步:

$ svn delete Project1/trunk
$ svn commit -m "Trunk deleted"
$ svn update
$ svn cp <URL of trunk>@6089 Project1/trunk
$ svn commit -m "Trunk recreated from r6089"

或者您可以从 Git 端更新它(确保您的工作树是干净的,然后再这样做):

$ git update-ref refs/heads/master <SHA-1 of r6089 commit>
$ git push origin master -f

如果您当前的分支是 master,您可能需要立即运行 git reset --hard HEAD

请注意,对应于 r6089 的 Git 提交不会丢失,对于没有引用的此类提交,SubGit 创建一个“阁楼”引用(以防止通过“git gc”收集它们),对于您的情况,它是 refs/svn/attic/trunk/6089,我想,这样你就可以获取

$ git fetch origin refs/svn/attic/trunk/6089:refs/heads/trunk6089

在客户端上进行此提交。请注意,之后您几乎不会注意到 r6109 的任何证据,svn log(以及 git log)将直接跳过它到最后一个替换源,即替换为 r6089。

另一种(更糟糕的)方法是从 SVN 历史记录中删除 r6109(我假设您没有其他对主干的提交)。这可以通过“svnadmin dump/load”过程来完成。在服务器上运行以下命令

$ svnadmin dump path/to/your/current/svn/repository -r1:6108 > repo.dump
$ svnadmin create path/for/repaiered/svn/repository
$ svnadmin load path/for/repaiered/svn/repository < repo.dump

然后配置对这个新存储库而不是您的 SVN 存储库的访问,并为其重新安装 SubGit。某些 SHA-1 哈希值可能会有所不同。有一种方法可以保留大部分哈希值,但这取决于您的 SubGit 模式:本地或远程。

你的 merge 方法怎么样,对我来说,这会使历史变得复杂。特别是如果您 merge 整个项目而不是某些分支,那么我不会执行该 merge 。

如果您有任何问题,请随时联系 support@subgit.com

关于git - SVN 主干被旧版本覆盖。项目和主干文件夹现在有不同的历史,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27964776/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com