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

Question

这是我在使用Subversion时遇到的一个奇怪的问题：当从开发分支合并到trunk（或者说回来）时，Subversion会将很多文件标记为已更改 - 而它们没有任何更改。

以下是发生的事情：

1. 在我的分支中，我提交了1个修改过的文件
2. 在trunk中我合并了该提交
3. 许多其他文件和目录被标记为“已修改”而实际上没有被更改（甚至没有空格，行结尾，属性或那种东西）。

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

知道什么可能导致这种麻烦，以及如何预防？我可以问Subversion为什么文件被标记为已修改，所以我会知道它是文件的内容，属性等吗？

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

Answer 1

一旦文件/文件夹具有显式mergeinfo（即svn:mergeinfo属性），即使文件/文件夹不相关，每次后续合并到分支也会更新该mergeinfo。这确实很烦人，因为它在每个合并的更改列表中引入了越来越多的混乱。

要避免这种情况，请仅合并到分支的“root”文件夹，例如“/branches/maintenance2.x”。 “/branches/maintenance2.x”下面的文件或文件夹都不应该获得mergeinfo。关注merging advice in the svn book。

不幸的是，即使您只在分支的“root”文件夹中进行合并，空的svn:mergeinfo属性在复制时仍会出现在单个文件和文件夹上，以表明它们没有收到相同的合并作为他们的兄弟姐妹。

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

---

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

Answer 2

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

我从未完全理解为什么会发生这种情况的确切原因，但它与泄漏的内部实施有关。试图理解它而不理解svn是如何实现的，据我所知，这是不可能的。但是，通常根本原因与子树合并有关。例如。如果合并子目录或单个文件的更改，而不是整个分支/标记。为了跟踪已合并的内容，subversion将mergeinfo属性放在最常规的节点上，但显然它在选择它时不够智能。您可以通过手动编辑mergeinfo来解决问题。只需从trunk下面的所有节点中删除该属性，并确保trunk在其mergeinfo中包含所有合并的修订版本。当然，这意味着您必须确保实际已合并更改。

总而言之，令人困惑的是，但好消息是，svn开发人员正在努力使整个事情变得更加顺畅。

Answer 3

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