我们有一个包含多个项目的SVN存储库:
ROOT
- Project1
- trunk
- Project2
- trunk
...等
然后我们开始迁移到git。我们设置 subgit 以保持SVN和GIT存储库同步(双向)。已经有几个月了,我们有一些开发人员使用svn,有些使用git,显然没有任何问题。
上面的每个项目都成为git存储库,子目录配置为:
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
现在,最后一个提交r6109看起来很可怕。似乎说当前的主干已被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 reset --hard
将工作副本重置到与svn r5477对应的提交处的本地主分支,并将其推送到远程主。Project1/trunk
,因此已使用r5477重写Project1
,这解释了为什么Project1
的历史记录仍然包含现在丢失的提交的日志(trunk中的代码实际上是回到r5477修改)。任何人都可以确认这可能是目前的状态吗?我还在忽视什么吗? 我不知道svn可以允许你(在这种情况下是subgit)最终会有不一致的历史记录。
如果这是真的,那么有人可以提出最佳解决方案吗?
请注意,git存储库没有历史记录的那一部分,因为它只同步Project1/trunk
而不是Project1
。
我觉得这应该在svn存储库中修复。但我不知道如何。
以下是可能的解决方案吗?
$ cd Project1
$ svn merge -rHEAD:6089 .
$ svn ci
警告和/或更好的建议吗?
答案 0 :(得分:3)
我会解释发生的事情。
在Git存储库中有一个'master'的更新,它绑定到SVN中的trunk。此外,更新是非快进的,默认情况下,Git不允许在没有-f
命令的git push
选项的情况下进行此类推送。
非快进更新将转换为分支替换,因为这是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
命令。如果您想严格禁止此类更新,可以在服务器上将receive.denyNonFastForwards
选项设置为Git配置的true
。
修复:有两种方法。如果您可以在Subversion历史记录中进行此类提交,则可以从trunk @ 6089再次替换trunk
。你可以从SVN那边做,例如分2步:
$ 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
如果您当前的分支是主分支,可能您现在需要运行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。 / p>
另一种(更糟糕的)方法是从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模式:本地或远程。
你的合并方法怎么样,对我来说这会让历史变得复杂。特别是如果您合并整个项目而不是某些分支,那么我就不会执行该合并。
如果您有任何问题,请随时联系support@subgit.com
答案 1 :(得分:0)
Dmitry Pavlenko提供的答案是正确的。一个重要的信息是,在SubGit bugreport中解释了Git提交和SVN修订之间存在1:1的关系。
为了防止这些分支替换发生,我们不同步包含斜杠的分支(默认的SubGit配置)并使用服务器端git hook(.git/hooks/user-pre-receive
):
#!/bin/bash
check_ref() {
OLD=$(git rev-parse $1)
NEW=$(git rev-parse $2)
REFNAME=$3
ZERO="0000000000000000000000000000000000000000"
if ! [[ $REFNAME == refs/heads/* ]]; then
# Not a branch action, probably a tag
return
fi
BRANCH_NAME=$(expr "$REFNAME" : "refs/heads/\(.*\)")
FEATURE_BRANCH=$(expr "$BRANCH_NAME" : "\(.*/.*\)")
if [ "$OLD" = "$ZERO" ]; then
if [ ${FEATURE_BRANCH} ]; then
# Permit feature branch creation
return
else
echo "*** Rejected creation of non-feature branch"
exit 1
fi
fi
if [ "$NEW" = "$ZERO" ]; then
if [ ${FEATURE_BRANCH} ]; then
# Permit feature branch deletion
return
else
echo "*** Rejected deletion of non-feature branch"
exit 1
fi
fi
if [ ${FEATURE_BRANCH} ]; then
# Pushes to feature branches are always allowed
return
fi
for COMMIT in `git rev-list $OLD ^$NEW`; do
# $COMMIT is reachable from $OLD, but not $NEW -> Force push
echo "*** Force push is not allowed on branch $REFNAME"
exit 1
done
# Check for non-fast-forward merge
ALL_REVS=`git rev-list $OLD..$NEW | wc -l`
REVS_WITH_SINGLE_PARENT=`git rev-list $OLD..$NEW --max-parents=1 | wc -l`
if [ ${ALL_REVS} -ne ${REVS_WITH_SINGLE_PARENT} ]; then
echo "*** Non-fast-forward merge detected on branch $REFNAME"
echo "*** Please rebase your work before pushing!"
exit 1
fi
for COMMIT in `git rev-list $OLD..$NEW`; do
# Checking commit $COMMIT
git branch --contains $COMMIT | grep -q -v / && echo "*** Commit $COMMIT rejected because it is contained in other branches" && exit 1
done
}
while read old new refname;
do
check_ref $old $new $refname
done
exit 0