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

Question

这是我在使用Subversion时遇到的一个奇怪的问题:当从开发分支合并到trunk(或者返回,就此而言)Subversion会将很多文件标记为已更改 - 而它们没有任何更改.

这是发生的事情:

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

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

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

仅供参考: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.遵循svn书中的合并建议.

不幸的是,即使您仅在分支的"根"文件夹中进行合并,在复制时,空svn:mergeinfo属性仍然可以显示在单个文件和文件夹上,以指示它们没有收到与其兄弟姐妹相同的合并.

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

这似乎已在SVN 1.7中修复.从发行说明:减少子树mergeinfo更改.

Answer 2

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

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

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

Answer 3

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