【问题标题】:Is it "safe" to merge individual files between branches in SVN?在 SVN 的分支之间合并单个文件是否“安全”?
【发布时间】:2012-10-04 15:00:53
【问题描述】:

如何在 SVN 中合并单个文件的问题一直是 answered before,所以我的问题是:这样做安全吗?如果我最终在某个时候合并整个分支,SVN 会“获取”特定文件已经被合并吗?如果我在合并整个分支之前来回合并更改会怎样?

【问题讨论】:

    标签: svn version-control merge


    【解决方案1】:

    是的,您可以合并单个文件,但这样做通常被认为是不好的做法

    问题在于 Subversion 使用 svn:mergeinfo 来跟踪合并。如果一个文件没有这个svn:mergeinfo 属性,它使用父目录的svn:mergeinfo。当您到处合并单个文件时,所有这些文件现在都有自己的 svn:mergeifno 属性。

    这会导致真正的问题吗?不,Subversion 工作正常。问题只是被察觉。每次 Subversion 更新 svn:mergeinfo 属性时,它都会创建该文件的另一个版本,即使该文件的内容没有改变。

    当您将主干合并到分支时(反之亦然),就会出现问题。你运行这样的命令:

    $ svn merge http://svn.mycorp.com/svn/project/trunk .
    

    您看到 100 多个文件已被修改,但您知道应该只合并 3 或 4 个文件。

    检查这些文件,您会发现唯一的区别是 svn:mergeinfo 属性已更改为表明您已将最新内容合并到这些文件中(即使它不会更改文件本身的内容)。没有真正的问题。只需允许 Subversion 在提交时更新这些文件的 svn:mergeinfo 属性,一切都很好。是的,如果您执行 svn log,合并将显示 100 多个文件在提交中发生了更改,但仔细查看会发现只有它们的 svn:mergeinfo 属性发生了更改。

    你不应该做的是revert这些文件。这将标志着更改没有合并到这些文件中(即使它没有更改它们的内容)。下一次合并将尝试重新合并上一次合并并造成更大的破坏。

    有时,当开发人员看到这一点时,他们开始向我抱怨修改。毕竟,如果文件本身没有变化,为什么还要修改这些文件呢?他们对svn:mergeinfo 的所有更改感到沮丧。

    这就是为什么认为最佳实践总是在项目的根目录而不是单个文件合并。这样,只有项目根目录下的目录获得 svn:mergeinfo 属性,而项目中的所有其他文件将简单地使用该 svn:mergeinfo 属性。

    如果您和您的所有开发人员都理解这一点,并且愿意容忍这种行为,那么合并单个文件就没有问题。由于这种并发症,通常不会这样做。

    【讨论】:

    • 谢谢,这正是我想要的答案!
    • 另一个使用 Git 的理由
    猜你喜欢
    • 1970-01-01
    • 2017-02-25
    • 1970-01-01
    • 1970-01-01
    • 2012-09-24
    • 2014-08-23
    • 2013-04-11
    • 1970-01-01
    • 2011-04-22
    相关资源
    最近更新 更多