有没有办法使用svn:mergeinfoclosuresTortoiseSVN?

当我做一个TortoiseSVN合并时,它包含了一堆目录,还有一些文件放到了修改后的文件中,即使没有实际的改变。

它改变了属性svn:mergeinfo

为什么需要在目录/文件上设置这些属性? 有什么方法svn:mergeinfosvn:mergeinfo进行这些更改吗?

我通常只是恢复项目,然后提交,但这浪费了额外的时间。

发生这种情况的可能性很大,因为这些文件和目录具有从前一个合并中设置的svn:mergeinfo属性。 我不认为合并单个文件或目录的方式通常会导致合并信息被写入单个文件。 您应该养成在工作stream程的最高级别进行合并的习惯,以便mergeinfo属性仅在结构目录(例如/ trunk或/branches/1.0)上设置。

但是,如果您在个别文件和文件夹中发现自己的mergeinfo属性,则可以执行以下两项操作:第一件事就是从相关文件和目录中删除svn:mergeinfo属性。 我不确定这是build议,除非你真的知道你在做什么,以及可能会产生什么效果。 在做这个之前阅读文档!

你可以做的第二件事是按照SVN希望你的方式来提交属性更改,如果你信任该软件,可能是正确的。

说了这么多,我一直在和我的队友一起工作,以便养成正确的习惯,这样我们就不会再有这种烦恼了。

SVN 1.7及更高版本

这应该在SVN 1.7中修复。 从发行说明 :

如果子树不受合并的影响,则合并不再在子树(具有自己的显式合并信息)上logging合并信息(描述合并)。 这应该大大减less具有显式合并信息的大量子树的用户的虚假svn:mergeinfo属性更改的数量。

SVN在1.7之前

会发生什么是一旦文件/文件夹有明确的合并信息,即使文件/文件夹是不相关的每一个后续合并到分支将更新该合并信息。 这很烦人,因为它在每个合并的变更列表中引入越来越多的混乱。

为了避免这种情况,只能合并到分支的“根”文件夹,例如“/branches/maintenance2.x”。 “/branches/maintenance2.x”下面的文件或文件夹都没有得到mergeinfo。 遵循SVN书中的合并build议 。

不幸的是,即使只在分支的“根”文件夹中svn:mergeinfo ,空svn:mergeinfo属性仍然可以在复制时出现在单个文件和文件夹中,以表明它们没有收到与其兄弟相同的合并。

删除多余的子树mergeinfo可能是安全的。 一种方法是通过recursion删除项目根目录中每个文件和文件夹的svn:mergeinfo属性。 (但保持mergeinfo在根文件夹本身!)

另外,你也可以升级到Subversion 1.6 。 我已经证实,它解决了这个问题。 它甚至似乎删除了由早期版本为您添加的多余mergeinfo。

从评论来看,SVN 1.6中仍然存在着多余的子树mergeinfo出现的情况。 但是我还没有能够重现这一点。

如果您使用–ignore-ancestry选项进行合并,则mergeinfo属性将不会首先创build。

 svn merge --ignore-ancestry -c 1234 svn://sourcecontrol . 

如果你打勾忽略祖先,它不会在文件夹中创buildsvn mergeinfo。 如果你已经获得了svn合并信息,只要恢复它并通过检查忽略祖先再次进行合并。

在这里输入图像说明

svn:mergeinfo是Subversion用来跟踪合并历史logging的属性。 我只是让它做它必须做的事情…您可能需要稍后合并历史跟踪,并发现它不起作用,因为您没有提交这些属性。

我会补充说,这个bug至less有一部分是在Subversion 1.5.5中修复的。 从1.5.5 CHANGES文件中 :

 do not create mergeinfo for wc-wc moves or copies (r34184, -585) 

也就是说,在1.5版之前的SVN中存在一个bug,它会创build一个没有使用的mergeinfo条目,而且是多余的,如果他们有很多svn:mergeinfo属性的话,原来的提问者可能会碰到这个bug。

堆栈溢出问题给出的命令删除不必要的svn:mergeinfo属性将删除任何额外的mergeinfo。

我们在我们的项目上recursion删除它,因为几乎所有的文件都有这个信息,这使得合并非常讨厌(如果只有一个文件已被更改,所有文件必须合并)。 从现在开始,我们只会在根上合并,以免今后出现这种情况。

到目前为止,还没有给我们任何问题。 日志logging仍然可以在文件上看起来是一样的(但是要自己承担风险!)。

哦,我们在我们的后备箱上做了,就在做一个新的分支之前。 这样,我们可以从一个干净的石板开始。

我们在团队中也遇到了这个问题,这使整个合并过程有点混乱。 读完这个之后,我尝试从多个文件中删除svn:mergeinfo属性,经过一些进一步的testing,看起来像是解决了这个问题。

伟大的问题和答案! 最近我们遇到了这个问题,因为我们正在努力解决自动化构build系统的局限性。 我们的构build系统会自动增加.bdsproj和一些带有版本和path信息的.dpr / .dpk文件。

我想改变这个……但是现在,如果你想合并一个分支到另一个分支,你得到了一些你改变的文件,然后是生成机器改变的1000个文件。 所以我们一直在做“有针对性”的合并,有时候是一个文件。 特别是对于具有合法更改的.dpr或.bdsproj文件(例如包含一个额外的单元)。 现在我知道发生了什么事情,所以我希望能阻止疯狂。

感谢堆溢出!