在将主干合并到分支后,Subversion的合并信息出现问题

4
我正在测试Subversion的最新版本,包括SVN命令行客户端和TortoiseSVN。(在此之前,我主要使用了引入合并信息属性和--reintegrate合并开关之前的版本。)
我已经进行了义务性的谷歌搜索,但是可能是我的搜索能力太差了,或者以下问题实际上是没有人解释和/或彻底解决的问题。我有点困惑,因为这里有很多有关该问题的报告 - 找到这些报告没有任何问题。我还发现了其他关于合并信息属性的讨论,但没有任何与我体验到的情况相匹配且解释/解决该问题的内容。
我希望能够提高我的搜索能力或者理解发生了什么事情以及该怎么处理。
以下是整个过程:
1. 我有一个主干(并且有一个基于它的工作副本) 2. 我创建了一个分支(并且有一个基于它的工作副本) 3. 我在主干的WC中进行了一些更改,并提交了 4. 我在分支的WC中做了一些工作并提交了 5. 现在我将主干的工作合并到我的分支的WC中,并解决所有冲突。
到目前为止都正常,但是当我尝试提交合并结果时,却收到一个消息,说明工作副本已过期,需要先更新。
这没有任何意义。合并之前,WC是最新的,合并的目标是WC。因此,在repo中不应该有任何改变。
深入挖掘发现,问题似乎在于合并信息属性本身。
我没有问题逐个提交更改的文件,但是之后WC仍然不干净/没有完全提交,并且因为WC不是最新的,我仍然无法提交。因此,Subversion似乎已经触及了repo和WC中的合并信息属性。
在这项调查中重复的情况下,我没有问题首先更新WC,然后再提交。但是我不确定是否始终如此,或者其他变体的现象是否更难解决。我也不希望尝试向附近的Subversion用户“解释”这个问题,他们并不将其视为其“主要工具”之一。
我已经反复测试了几年,并且我认为这个问题从合并信息和--reintegrate功能(1.5?)引入到现在都存在。可以这样吗?而且它仍然没有得到解决吗?
我的当前测试是使用命令行客户端(从CollabNetSubversion-client-1.6.17-4.win32.exe安装)和TortoiseSVN(TortoiseSVN-1.6.16.21511-win32-svn-1.6.17.msi),并且我得到相同的结果。
我已经使用Subversion很多年了,并自认为是一个“高级用户”。但是,对于这个问题,我束手无策。
补充说明:
以下是我能够重现问题的步骤:
1. 在“C:\Documents and Settings\johndoe\My Documents\SVN\Repo”中创建一个仓库。 2. 使用Repo浏览器,在“file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Trunk”中创建一个分支(r1)。 3. 使用Repo浏览器,在“file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Branches”中创建一个分支(r2)。 4. 在“C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Trunk”中创建一个工作副本(不生成新的版本)。 5. 在Trunk中创建一个文本文件test.txt,添加并提交(r3)。 6. 在“file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Branches/Branch1”中创建Trunk的一个分支(r4)。 7. 在“C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1”中创建一个工作副本(不生成新的版本)。 8. 在基于Trunk的工作副本中,将一行文本添加到test.txt并提交(r5)。 9. 在基于Branch1的工作副本中,将一行文本添加到test.txt并提交(r6)。 10. 将Trunk合并到Branch1。右键单击“C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1”,选择Tortoise SVN,选择Merge。选择“Merge a range of revisions”作为合并类型,URL to merge from: "file:///C:/Documents and Settings/johndoe/My Documents/SVN/Repo/Trunk",Revisions to merge:,Working copy: "C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1",其余默认。在解决冲突对话框中选择“稍后全部解决”(不生成新的版本)。 11. 解决冲突。右键单击文件,选择Tortoise SVN,选择Edit Conflicts。在TortoiseMerge中,标记并选择“Theirs before mine”,点击“Mark as resolved”,保存并退出(不生成新的版本)。 12. 尝试提交Branch1中的更改。
此时我会收到一条消息。
Commit
C:\Documents and Settings\johndoe\My Documents\SVN\WCs\Branch1
Commit failed (details follow): 
Directory '/Branches/Branch1' is outof date 
You have to update your working copy first.

这对我来说没有意义:合并之前,工作副本是最新的。此后没有创建新的修订版本(repo HEAD仍为r6),现在我的工作副本不再是最新的。
进一步调查发现,在第9步和第10步之间更新Branch1的WC可以解决问题。同样,这对我来说毫无意义: i)在更新结束时的对话中,没有报告实际更新的内容, ii)分支中唯一更改的事情已经提交。
因此,在我看来,WC既是“干净的”(没有未提交的内容),也是“最新的”(repo中没有要贡献给WC的内容)。
更新实际上唯一做的是将Branch1的工作副本的BASE从r4更改为r6。这在某种程度上很重要,但现在我的头脑太混乱了,无法确定细节。
我会欣赏任何新的想法,使我看到这里发生了什么。
补充2
进一步尝试澄清我的思路:指向的FAQ说
3个回答

2
这与合并信息属性无关,而是因为在文件夹上修改了属性(好吧,在这种情况下是合并信息属性)。

请参阅有关此问题的常见问题解答


有点尴尬,我没有找到那个常见问题解答。抱歉。 - johanekdahl
很尴尬,我没有找到并阅读那个常见问题解答,但我看不出它适用于我的情况。它谈论了“酸提交”和“混合版本”。我的工作副本干净(在r26上提交并更新)。我以该工作副本为目标进行合并。存储库仍然是r26。当我尝试提交合并结果时,SVN说我的工作副本已过期,但自从我更新后没有创建任何新的修订版本。我猜我缺少一些基础知识,这也是令人尴尬的,但我简直看不到它。 - johanekdahl
好的,我进行了新的测试,如果我必须解决任何冲突,问题就会100%重现。如果Subversion能够在没有我的帮助/干预的情况下完成合并,一切都会很顺利。 - johanekdahl
继续我的调查,并准备好提供一个干净、经过深思熟虑且可重复的示例。现在我无法重复它... 我会继续努力,有了实质性的进展后再回来。感谢您的参与,Stefan! - johanekdahl
请注意:我原来的问题已经添加了大量补充说明,其中包括重现这个“现象”的步骤。 - johanekdahl
进一步思考,我想知道“文件夹上的属性被修改”这个问题。在我看来,该属性尚未提交,因此仓库在这个意义上没有更新版本。当然,除非合并实际上立即提交了此合并信息,这是一个非常可怕的想法。以工作副本为目标的合并不应该改变任何东西,只会改变工作副本。现在就去测试一下吧。 - johanekdahl

0

经过一些实验,Stefans的回答更有道理。他关于这不是特定于合并信息属性的说法是绝对正确的。我通过在分支的工作副本的顶层文件夹上放置自己的任意属性来验证了这一点。

我仍然对公式很好奇

在某些操作(例如目录属性修改)中, 如果存储库具有节点的更新版本,则会拒绝提交以防止数据丢失。 从分支开始(分支已生成r4)我

  • 创建此分支的WC(此时,顶级目录和该目录中唯一的文件都是最新的且干净的(没有未提交的更改))。
  • 编辑文件并提交(HEAD为r5,目录的COMMITTED为r4,文件的COMMITTED为r5)
  • 在WC上的目录中放置一个属性

再次尝试提交时,我仍然遇到错误。问题出在文件夹节点上。

SVN STAT产生:

C:\SVN T2\WCs\Branch1>svn stat
 M      .

DIF文件显示了一个变化,即文件夹(添加的属性):

C:\SVN T2\WCs\Branch1>svn diff

Property changes on: .
___________________________________________________________________
Added: je:dummy
   + Dummy value

最后,INFO 说:

C:\SVN T2\WCs\Branch1>svn info
Path: .
URL: file:///C:/SVN%20T2/Repo/Branches/Branch1
Repository Root: file:///C:/SVN%20T2/Repo
Repository UUID: 009c3a97-e14f-234a-92e9-d30c537e29f9
Revision: 4
Node Kind: directory
Schedule: normal
Last Changed Author: SEEKDAHLJ
Last Changed Rev: 4
Last Changed Date: 2011-07-27 09:26:53 +0200 (on, 27 jul 2011)

我的目录基础是r4,HEAD也是r4,并且我有一个未提交的更改。我看不出可能会有什么冲突。

如果有人能够解释一下这个问题,我将不胜感激。我错过了什么?

进一步尝试,进行类似的序列,但是向目录添加文件而不是添加属性,就没有这样的冲突。

所以,是的,这与特定的属性有关,我剩下的问题是,是否有人能够描述一个实际发生冲突的情况?


0

你并不孤单:我也看到了这个问题。它似乎不会引起问题,并且在你试图提交属性到一个有来自后续版本的子节点的文件夹时表现出来。因此,在某种意义上,你的节点有一个更新的版本:来自后续版本的版本与来自早期版本的版本具有不同的子节点。我没有查看过代码,但我想象这些子节点以类似于属性存储的方式存储在节点上。


我知道我不是一个人。但目前我认为/理解"我的节点"没有新版本。当我有时间时,我会在旧版本("预重新集成")上进行测试,并确认那里不会发生这种情况。就个人而言,我在使用SVN时更新没有问题,但是...我帮助/教授其他人使用SVN,并且我建立在对"底层模型"的推理上,而这种现象破坏了我对该模型的看法。我讨厌不得不说"好吧,这里有一些我无法解释的东西-只能接受它很奇怪,你将不得不..."。下一个教学活动将于9月12日举行。救命啊! - johanekdahl

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接