2009-02-21 107 views
6

我有一个在颠覆控制下的目录。我只是为了测试合并的东西而创建了一个分支。我拿了一个文件,把trunk中的第X行修改为“abc”,并在其分支中将同一行X修改为“def”。SVN合并问题

然后,从分支工作目录我所做的:

svn merge branchURL trunkURL . 

它更新了该行号的内容为“ABC”的文件,即它并没有给我在同一行号冲突因为svn update会给我,如果我在同一个工作目录中完成它并且有人在存储库中提交了“def”。

那么svn merge只是在合并时替换内容而不会带来任何冲突?

如果是这样的话,当不能以某种方式合并以保持树干和分支的变化时,将主程序分支出主干的非常有用。

+0

所以你1)分支2)修改后的行X到主干上的“abc”3)切换到分支4)修改后的行X到分支上的“def”5)合并?在将其修改为“abc”之前,X行的内容是什么? – 2009-02-21 23:45:45

+0

我想在我的办公室b/w我的客户端svn和服务器svn会有一个版本差异,因为我记得最近我将svn版本升级到了1.5版本,并且在回购版存在的服务器上没有发生这种情况。所以我没有得到冲突的事实可能是版本差异的结果。 – ashishsony 2009-02-22 12:53:34

回答

6

你一定要明白什么

svn merge branchUrl trunkUrl branchWorkingCopy 

其实呢,是吗?

这里有一个翻译:

找出一套必要作出branchUrl等同于那些trunkUrl的内容变化。现在在branchWorkingCopy上执行这些更改。

您不会因此合并任何冲突。但是,当您检入branchWorkingCopy时,您将使您的分支与您的主干相同,这几乎肯定不是您想要的。

如果你只是想选择的变化从干线复制到分支,你需要告诉Subversion 变化要复制并使用不同的形式合并命令:

svn merge -r100:103 trunkUrl branchWorkingCopy 

这意味着:确定在trunk上从r100到r103所需的一组更改。在工作副本(分支)上执行这些更改。请注意,此“一组更改”将不包含r100所做的更改,因为这些更改是由从r99到r100所需的一组更改捕获的。 Subversion版本范围为,开放时间为

另外,如果你还没有,请考虑阅读fine manual

0

所以做了svn合并只是取代 的内容,同时合并和不 带来什么冲突?

那么,没有。我无法真正指出你做错了什么,但合并标志冲突与更新相同。

0

我可能会丢失一些东西,但是当我使用svn merge时,如果我希望它正常工作,我总是必须获得修订号。

所以,如果你在版本100支(或最后合并),树干目前为200,和你想从主干的修改合并到分支,然后在该分支的工作目录,你做的事:

svn merge -r 100:200 trunkURL 

然后我想你会看到一个冲突,你解决并检查。你在干线工作目录中做类似的事情,从分支合并到干线。

不带-r的svn合并比较您指定的两个位置,并将该diff应用于工作目录。所以我推测发生了什么事情就是没有冲突,因为你的工作目录和分支的头相匹配。因此,分支头部和干线头部之间的差异可以毫无问题地应用于您的工作目录。这不是你想要做的:它所做的只是改变你的工作目录以匹配主干。尝试在分支上进行另一次更改,检入并重复该过程。如果合并解除了这个改变(因为它不在主干上),那么我对这种svn合并的形式是正确的,但正如我所说我没有使用它。

[编辑:之前SVN版本1.5 ...]

工作目录和分支机构不在SVN同样的事情,和恼人的,因为它是你必须考虑的差异。 SVN需要更多的信息来做你想要的分支合并,而不是进行更新或签入,因为afaik并不会自动考虑分支发生的位置,它总是占用工作目录的检出位置。我确信有一个原因,我只是不知道它是什么,可能是因为svn副本比分支更多。

[编辑...但按照Joshua McKinnon对此答案的评论,从1.5开始,svn支持正确的分支合并,它可以自动执行所需的操作。指定要合并的URL,然后在合并到的任何工作目录中运行该命令。所以在这种情况下,尝试

svn merge trunkURL 

,你应该看到的冲突。您可能必须先恢复工作目录。]

+0

直到颠覆1.5,我相信这一直是必要的。现在,来自目标workspce的直接'svn merge sourceURL'会将所有未记录的修订合并到subversion的元数据中。 – 2009-02-21 03:28:28