SVN 树冲突和目录丢失问题

江河水 发布于 2010/10/29 10:44
阅读 17K+
收藏 5

SVN 树冲突和目录丢失问题(1

临下班了,一个老朋友 (之后用yzw代称) MSN 上呼我。说他的 SVN 遇到问题了:

·             在执行分支合并时,一个目录发生了树冲突

·             直接在硬盘上将该目录删除

·             之后执行 svn update 该目录不能检出

·             不知道树冲突为何物,也不知道目录怎么变成了一团糟

好吧,谁让他公司的 SVN 是我给部署的呢?让他(yzw)执行 svn status 命令,看看显示什么信息,然后我在本地建立一个模型,争取重现并解决他的问题。

在已经一团糟的目录下,执行 svn 显示的信息如下:

$ svn st

 M      .

!  +  C somedir

      >   local add, incoming add upon update

看来他遇到的树冲突,是因为在两个分支同时创建了一个同名目录 somedir,然后在合并更新时出现树冲突。

重现问题的过程

版本库准备

1.           创建svn 版本库于 /tmp/svnserver

2.           检出版本库到目录 ~/tmp/svntf windows用户需要知道的是:~ 代表我的主目录 /home/jiangxin 是也)

3.           创建 SVN 三个顶级目录:trunk tags branches

4.           创建分支 branches/0.x

5.           branches/0.x 分支下创建目录 somedir,并增加一个文件 somedir/branch.txt

6.           在主线 trunk 下也创建一个目录 somedir,并增加一个文件 somedir/trunk.txt

看看目前的版本情况

1.           主线下执行 svn info

2.                ~/tmp/svntf/trunk$ svn info

3.                路径: .

4.                URL: file:///tmp/svnserver/trunk

5.                版本库根: file:///tmp/svnserver

6.                版本库 UUID: c0e3cb0f-81b0-40e5-9c35-42972dbc50aa

7.                版本: 4

8.                节点种类: 目录

9.                调度: 正常

10.            最后修改的作者: jiangxin

11.            最后修改的版本: 4

最后修改的时间: 2010-04-22 19:51:55 +0800 (, 2010-04-22)

12.        主线下目录下的文件

13.            ~/tmp/svntf/trunk$ svn ls -R

14.            somedir/

somedir/trunk.txt

15.        主线的更改历史

16.            ~/tmp/svntf/trunk$ svn log

17.            ------------------------------------------------------------------------

18.            r4 | jiangxin | 2010-04-22 19:51:55 +0800 (, 2010-04-22) | 1

19.             

20.            to trunk, we add somedir/trunk.txt file.

21.            ------------------------------------------------------------------------

22.            r1 | jiangxin | 2010-04-22 19:48:57 +0800 (, 2010-04-22) | 1

23.             

24.            initial

------------------------------------------------------------------------

25.        分支的中的文件列表

26.            ~/tmp/svntf/trunk$ svn ls -R file:///tmp/svnserver/branches/0.x

27.            somedir/

somedir/branch.txt

28.        分支的更改历史

29.            ~/tmp/svntf/trunk$ svn log file:///tmp/svnserver/branches/0.x

30.            ------------------------------------------------------------------------

31.            r3 | jiangxin | 2010-04-22 19:51:21 +0800 (, 2010-04-22) | 1

32.             

33.            to branch 0.x, we add somedir/branch.txt file.

34.            ------------------------------------------------------------------------

35.            r2 | jiangxin | 2010-04-22 19:50:27 +0800 (, 2010-04-22) | 1

36.             

37.            trunk => branch/0.x

38.            ------------------------------------------------------------------------

39.            r1 | jiangxin | 2010-04-22 19:48:57 +0800 (, 2010-04-22) | 1

40.             

41.            initial

------------------------------------------------------------------------

备份当前的 .svn 目录

直接拷贝 .svn .svn-orignal,以便在出现意外的时候,进行参照。

~/tmp/svntf/trunk$ cp -a .svn .svn-orignal

Tips: 如果不想每次在执行 svn status 时显示 .svn-orignal 目录,设置svn属性 svn:ignore 值为 “.svn*”。(问题优点复杂化了,算了)

合并分支改动,引发异常

1.           执行合并操作,引发异常

2.                ~/tmp/svntf/trunk$ svn merge file:///tmp/svnserver/branches/0.x

3.                --- 正在合并 r2,经由 r4,到 “.”:

4.                   C somedir

5.                冲突概要:

  树冲突:1

6.           删除 somedir 目录

~/tmp/svntf/trunk$ rm -rf somedir/

7.           执行 svn status 查看当前状态

8.                ~/tmp/svntf/trunk$ svn st

9.                 M      .

10.            ?       .svn-merge-conflict

11.            ?       .svn-orignal

12.            !     C somedir

13.                  >   本地 增加,动作 增加,操作 合并

14.        虽然结果和yzw很像了,但是还不是完全一致。

o                yzw 执行 svn status 显示的英文,最后一行翻译为中文是:

      >   本地 增加,动作 增加,操作 更新

o                而我的结果是:

      >   本地 增加,动作 增加,操作 合并

o                看来,还需要作些工作才能完全重现错误。

15.        这时我又备份了一下 .svn 目录,将 .svn 复制到 .svn-merge-conflict,以便后面比较

16.        执行 svn up 命令

17.            ~/tmp/svntf/trunk$ svn up

18.            跳过“somedir”

19.            D    somedir

20.            更新到版本 4

21.            冲突概要:

22.              跳过的路径:1

23.            ~/tmp/svntf/trunk$ svn up

版本 4

24.        以上执行了两次 svn up ,结果不一致,说明 svn 干了些什么。
实际上,通过比较 .svn 目录和之前备份的 .svn-merge-conflict 可以看出端倪:

25.            ~/tmp/svntf/trunk$ diff -r .svn-merge-conflict .svn

26.            diff -r .svn-merge-conflict/entries .svn/entries

27.            38,40d37

28.            < somedir

29.            < dir

<

30.        执行 svn 恢复操作,再执行 svn up,发现 somedir 没有了:

31.            ~/tmp/svntf/trunk$ svn revert -R .

32.            已恢复“somedir”

33.            ~/tmp/svntf/trunk$ svn up

34.            版本 4

执行 svn status,看到本地工作目录的冲突状态已经消失了,一切看起来正常了。

~/tmp/svntf/trunk$ svn st

?       .svn-merge-conflict

?       .svn-orignal

但是,慢着,此时 somedir 目录没有了!

~/tmp/svntf/trunk$ ls

实际上,这时版本库中还有 somedir 目录,我们可以用 svn ls 命令查看:

~/tmp/svntf/trunk$ svn ls -R

somedir/

somedir/trunk.txt

但是本地的确已经没有了。如果要刨根问底的话,可以比较一下 .svn 目录和我们之前创建的备份:

~/tmp/svntf/trunk$ diff -r .svn-orignal .svn

diff -r .svn-orignal/entries .svn/entries

38,40d37

< somedir

< dir

<

35.        这时如果再执行从分支合并,合并的过程就很有意思了
居然没有发生冲突。yzw 这时后一定很欣喜,居然可以成功合并了。

36.            ~/tmp/svntf/trunk$ svn merge file:///tmp/svnserver/branches/0.x

37.            --- 正在合并 r2,经由 r4,到 “.”:

38.            A    somedir

A    somedir/branch.txt

39.        但是慢着,这个合并是假的。不信提交看一看

40.            ~/tmp/svntf/trunk$ svn st

41.             M      .

42.            ?       .svn-merge-conflict

43.            ?       .svn-orignal

44.            A  +    somedir

45.            A  +    somedir/branch.txt

46.            ~/tmp/svntf/trunk$ svn ci -m "merge from branch 0.x"

47.            正在发送       trunk

48.            增加           trunk/somedir

49.            svn: 提交失败(细节如下):

svn: 目录 “/trunk/somedir” 已经过时

50.        提交过时?很简单,SVN 的经典问题:服务器有更新的版本,更新之

51.            ~/tmp/svntf/trunk$ svn up

版本 4

52.        执行 svn update 没有反应?带目录执行 svn update 试试,果然发生冲突了:

53.            ~/tmp/svntf/trunk$ svn up somedir

54.             C somedir

55.            版本 4

56.            冲突概要:

 树冲突:1

57.        查看冲突的状态,是不是和 yzw 的一致了

58.            ~/tmp/svntf/trunk$ svn st

59.             M      .

60.            ?       .svn-merge-conflict

61.            ?       .svn-orignal

62.            A  +  C somedir

63.                  >   本地 增加,动作 增加,操作 更新

A  +    somedir/branch.txt

64.        不太一样?删掉 somedir 先。然后看状态:

~/tmp/svntf/trunk$ rm -rf somedir

再看看状态?

~/tmp/svntf/trunk$ svn st

 M      .

?       .svn-merge-conflict

?       .svn-orignal

!  +  C somedir

       >   本地 增加,动作 增加,操作 更新

SVN 树冲突和目录丢失问题(2

前面的博文《SVN 树冲突和目录丢失问题(1》,介绍了重现 update 导致树冲突的重现过程。那么应该如何解决树冲突,以及如何找回丢失目录呢?首先我们需要了解:

什么是树冲突?

首先关于树冲突的概念,最好的参考是:SVN BOOK的有关树冲突的章节

·             平时我们说的冲突,是因为对同一文件的不同修改造成的冲突。

·             树冲突,指的是由于目录(文件)树的改变,造成内容修改修改不能匹配在同一对象(目录/文件)上

·             例如:由于在一个分支中修改的目录和文件,在另外的分支出现了改名的操作。

·             或者像 yzw 的例子,因为两个分支同时增加了一个同名的目录,导致了树冲突。

树冲突的解决,首先要说的是要最好使用 svn 1.6 的客户端。因为 svn 1.5 的客户端对树冲突的处理不好,甚至根本发现不了树冲突,很容易忽略潜在的冲突,出现意想不到的结果。

SVN BOOK 中举了一个本地修改,远程重命名的例子。

例如 svn 1.5 处理这种本地修改/远程文件改名的情况,可能会出现如下结果:

·             发现远程改名,则检查本地文件是否包含修改,若不包含修改直接删除。

·             结果因为远程改名的文件,本地包含修改,因此不删除,而是保留该文件,但是文件的状态变为未受版本控制状态。

·             本地会显示一个新增文件,实际上是本地修改文件的原始(修改前)版本重命名后的文件。

·             这时,如果不太细心(谁那有那么细心?),就会丢失本地的改动。

对于 svn 1.5 最困难的是发现冲突,当然解决冲突也要靠手工比较完成:将本地文件改动在重命名后文件中再次改动一次!

对于 svn1.6 来说,引入了树冲突的概念,看似复杂度增加了,实际上是解决了两个问题:

·             识别冲突的问题:
将本地修改的文件标记为树冲突

·             改动合并的问题:
将本地修改合并到远程改名后的文件中。因为远程改名后的文件来自于本地修改的原始文件

当然对于远程重命名的例子,还要你最终的决定权还是在于你自己:

·             是否接受远程的文件重命名操作?

·             你需要手动将树冲突的状态予以解决:本地文件删除即接受远程重命名;

·             或者将远程添加的文件删除即不允许重命名。

·             对于前一种状况(即接受远程重命名),本地改动 SVN 1. 6的客户端已经自动合并到远程改名后的文件中了。

那么对于 yzw 的情况呢?

本地和远程同时添加目录?

yzw 遇到的树冲突,是因为本地和远程同时添加了相同的目录。实际上,我们在上一个博客中已经看到了两种不同的解决方案影子:

·             本地添加 somedir 目录并提交后,执行合并,显示:合并引发的树冲突

o                这时,如果执行 svn resolve –accept working somedir 命令解决冲突的话,

o                就相当于说:采用我增加的 somedir 目录,他增加的 somedir 目录不算数

o                然后提交即可

·             树冲突发生后:

o                还原冲突

o                删除主线中的目录。潜台词是:我本地的修改不要了,而是使用远程(分支)添加的目录

o                然后再执行从分支到主线的合并操作

o                合并成功,提交。

o                也就是说,采用的策略是:采用他增加的 somedir 目录,我增加的 somedir 目录不算数

看看实际操作的例子:

接受我的修改,远程的修改不算数

·             合并引发树冲突状态

·                    ~/tmp/svntf/trunk$ svn st

·                     M      .

·                    ?       .svn-merge-conflict

·                    ?       .svn-update-conflict

·                    ?       .svn-orignal

·                          C somedir

·                          >   本地 增加,动作 增加,操作 合并

·             使用 svn resolve –accept working 解决冲突:
~/tmp/svntf/trunk$
 svn resolve –accept working somedir
“somedir”
的冲突状态已解决
~/tmp/svntf/trunk$ svn st
M .
? .svn-merge-conflict
? .svn-update-conflict
? .svn-orignal

·             显示的目录的属性有改变,是因为增加了一个 svn:merge-info 属性

·                    ~/tmp/svntf/trunk$ svn pl -v .

·                    “.” 上的属性:

·                      svn:mergeinfo

·                        /branches/0.x:2-4

·             提交合并的结果

·                    ~/tmp/svntf/trunk$ svn ci -m "忽略分支 0.x 的改动,我的增加是对的。"

·                    正在发送       trunk

·                     

·                    提交后的版本为 5

·                    ~/tmp/svntf/trunk$ svn st

·                    ?       .svn-merge-conflict

·                    ?       .svn-update-conflict

·                    ?       .svn-orignal

·                    ~/tmp/svntf/trunk$ svn pl -v .

·                    “.” 上的属性:

·                      svn:mergeinfo

    /branches/0.x:2-4

接受远程的修改,我的修改不算数

上一个博文中,我几经尝试,进入到了由于更新引发的树冲突。但是在上一个博客示例最后的更新引发树冲突的状态,虽然也可以用 svn resolve 命令解决树冲突,但是无法提交。

总是报错

~/tmp/svntf/trunk$ svn st

 M      .

A  +  C somedir

      >   本地 增加,动作 增加,操作 更新

A  +    somedir/branch.txt

~/tmp/svntf/trunk$ ls somedir

branch.txt

~/tmp/svntf/trunk$ svn resolve --accept working somedir

“somedir”的冲突状态已解决

~/tmp/svntf/trunk$ svn st

 M      .

A  +    somedir

A  +    somedir/branch.txt

~/tmp/svntf/trunk$ svn ci -m "删除我的增加的目录,分支 0.x 的增加是对的。"

增加           somedir

svn: 提交失败(细节如下):

svn: 目录 “/trunk/somedir” 已经过时

无论你如何执行 svn update,解决过时错误,也仍然不能提交。会陷入一个无穷无尽的冲突解决==>过时冲突的循环中。

一个撤销本地修改,接受远程分支修订的解决的办法是:

1.           还原

2.                ~/tmp/svntf/trunk$ svn revert -R .

3.                已恢复“.”

4.                已恢复“somedir”

5.                ~/tmp/svntf/trunk$ svn up

6.                版本 4

7.                ~/tmp/svntf/trunk$ svn st

?       somedir

8.           找回在 .svn/entries 中已经丢弃的 somedir我使用 svn up –set-depth infinity 但是并不能更新出来。如果先执行 –set-depth 为其他,在执行 –set-depth infinity 倒是能够找回 somedir。但是这个方法太过奇怪,好像是 SVN 的一个 BUG,通过奇怪的操作绕过去了一样。我用下面的命令找回丢失的 somedir 目录:

9.                ~/tmp/svntf/trunk$ rm -rf somedir/

10.            ~/tmp/svntf/trunk$ svn up

11.            版本 4

12.            ~/tmp/svntf/trunk$ svn up somedir

13.            A    somedir

A    somedir/trunk.txt

14.        svn 命令删除 somedir目录,并提交

15.            ~/tmp/svntf/trunk$ svn rm somedir/

16.            D         somedir/trunk.txt

17.            D         somedir

18.             

19.            ~/tmp/svntf/trunk$ svn ci -m "丢弃我的改动"

20.            删除           trunk/somedir

21.             

提交后的版本为 5

22.        然后将分支 0.x 合并到主线,因为本地目录已经不在,合并不会出现冲突了

23.            ~/tmp/svntf/trunk$ svn merge file:///tmp/svnserver/branches/0.x

24.            --- 正在合并 r2,经由 r5,到 “.”:

25.            A    somedir

26.            A    somedir/branch.txt

27.            ~/tmp/svntf/trunk$ svn st

28.             M      .

29.            A  +    somedir

30.            A  +    somedir/branch.txt

31.            ~/tmp/svntf/trunk$ svn ci -m "删除我的增加的目录,分支 0.x 的增加是对的。"

32.            正在发送       trunk

33.            svn: 提交失败(细节如下):

34.            svn: 目录 “/trunk” 已经过时

35.            ~/tmp/svntf/trunk$ svn up

36.            版本 5

37.            ~/tmp/svntf/trunk$ svn ci -m "删除我的增加的目录,分支 0.x 的增加是对的。"

38.            正在发送       trunk

39.            增加           trunk/somedir

40.            增加           trunk/somedir/branch.txt

41.             

42.            提交后的版本为 6

中间出现了一次过时问题,是因为目录属性修改,而目录的版本号尚未更新。这其实是 svn 混杂版本号造成的,已经超出本博文的内容。

总结

好了,通过这个例子,我介绍了增加同名目录引发的树冲突的解决方案。

·             如何保留本地修改,取消远程修改

·             如何取消本地修改,保留远程修改

·             怎样的操作,会使 svn 进入一个无法解决的冲突合并状态,以及如何解决

·             发现了一个 SVN 本地目录丢失无法通过  svn update 找回的问题,以及两种解决方法:

o                一个很古怪:分别使用不同的 –set-depth 值执行多次 update,不过最终会成功

o                另外一个却需要知道丢失的目录名称,如果不知道本地有哪个目录缺失,就很难操作了

老杨是我见过的最牛的程序员,但是他的 CVS 的死忠和对 SVN 的憎恨让我觉得异常诧异。可能他和Linus Torvalds 很想像,但又有不同,因为 Linus CVS SVN 同样憎恨。

我估计老杨一旦有时间,一旦掌握了 Git,他就会把 CVS (还有SVN?)扔到九霄云外。不过我估计他还得需要 SVN GIT 接合使用,因为毕竟他现在做的是商业软件开发,还需要精细的代码授权(至少是对别人授权)。

加载中
0
sdfsadfasd
sdfsadfasd

牛人啊,我根本看不懂……

请教个问题,为什么我改了个文件,在revert的时候就说目录已经锁了?害我只能把工程删除,在服务器上重下,好麻烦

0
江河水

svn cleanup 以删除锁

0
sdfsadfasd
sdfsadfasd

可是我没看到svn cleanup

0
江河水

命令行的话输入命令 svn cleanup 。图形界面如乌龟SVN,菜单上叫做清除或者其他什么,仔细找找能看到。

0
返回顶部
顶部