Subversion将修改后的文件标记为已修改

下面是我使用Subversion遇到的一个奇怪问题：从开发分支合并到主干（或者返回，就此而言）Subversion会将很多文件标记为已更改 - 虽然它们没有更改。Subversion将修改后的文件标记为已修改

这里发生了什么：

在我的分支我承诺1修改后的文件
在后备箱我在合并提交
很多其他文件和目录被标记为“修改”没有实际上已经被改变了（甚至没有空白，行尾，属性或者那种东西）。

从技术上讲，提交这些不变的更改将没有什么区别，但我不想在我的日志中添加噪音。

任何想法可能会导致这种滋扰，以及如何预防它？我可以问Subversion为什么一个文件被标记为已修改，所以我会知道它是否是文件的内容，属性等？

FYI：颠覆客户端在1.6.x范围内，服务器在1.5.x范围内。在Mac OS X Leopard上使用Versions.app和CLI的组合。

来源

2009-09-30 avdgaag

会发生什么情况是，一旦文件/文件夹具有显式合并信息（即svn:mergeinfo属性），即使文件/文件夹不相关，每次后续合并到分支都会更新该合并信息。这确实令人讨厌，因为它在每个合并的变更列表中引入越来越多的混乱。

为了避免这种情况，只能合并到分支的“根”文件夹，例如“/branches/maintenance2.x”。 “/branches/maintenance2.x”下面的文件或文件夹都不应该获取mergeinfo。按照merging advice in the svn book。

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

如果你只在根上合并，那么删除多余的子树mergeinfo可能是安全的。一种方法是通过递归删除项目根目录中每个文件和文件夹上的svn:mergeinfo属性。

这似乎已经在SVN 1.7中修复。从发行说明：Reduced subtree mergeinfo changes。

来源

2009-09-30 13:14:11

你好@Coenen，我可以忽略只显示svn：mergeinfo中提交的文件，而提交。即我不提交这些文件？将工作..还是会把事情搞砸？ – mtk 2015-05-07 08:40:19

我正在使用TortoiseSVN。另外我看到一个选项来恢复文件。我可以用它吗？我只谈论那些实际上没有修改但在修改列表中显示为“已修改”的文件。 – mtk 2015-05-07 08:43:20

@mtk：就像我说过的，如果只在项目的根目录下合并，这些* *可能是安全的。 – 2015-05-08 15:16:38

它可能是某种属性更改，可能是svn：mergeinfo属性的一些自动修改。你可以通过运行“svn stat”来判断它是否属性修改。如果“M”位于第一列，则表示内容有变化，如果它在第二列，则表示属性发生变化。

来源

2009-09-30 08:59:51 sunny256

'svn stat' thingy非常有帮助，谢谢。 – avdgaag 2009-09-30 09:10:35

更改位于文件属性中。如果您运行svn proplist，您将看到很多mergeinfo条目。这是因为svn跟踪文件属性中的合并。这是1.5中的一个新功能，因此它在旧版本中不会发生。

我从来没有完全理解这种情况发生的确切原因，但它与内部泄漏实现有关。试图了解它而不理解svn是如何实现的，就我所得出的结论而言，这是不可能的。但是，通常是的根本原因与子树合并有关。例如。如果合并子目录或单个文件的更改，而不是整个分支/标记。为了追踪已经合并的内容，Subversion会将mergeinfo属性放在最普通的节点上，但显然它在拾取它时不够智能。您可以通过手动编辑mergeinfo来解决问题。只需从主干下的所有节点中删除该属性，并确保该主干在其mergeinfo中具有所有合并修订。当然，这意味着您必须确保这些更改实际上已合并。

总的来说相当困惑，但好消息是svn devs实际上是正在努力使整个事情更加流畅。

来源

2009-09-30 09:00:32 troelskn

确认，谢谢。后续：为什么这会适用于某些文件，而不适用于其他文件？我应该进行这些更改吗？ – avdgaag 2009-09-30 09:09:51

Subversion将修改后的文件标记为已修改

回答

相关问题