diff文件的格式

diff
参考http://en.wikipedia.org/wiki/Diff
diff是一个比较工具，它比较两个文件，然后输出两个文件的差异，这个差异文件叫做diff文件。它通常被用来找出同一文件两个版本之间的差异。所谓差异，就是指从原文件到新文件增加了哪些，删除了哪些。

diff的算法
实现diff功能的算法基础是最长公共子序列 longest common subsequence problemhttp://en.wikipedia.org/wiki/Longest_common_subsequence_problem.
中文解释见http://hxraid.iteye.com/blog/622462
例如下面两个串
      S1: a b c d f g h j q z
      S2: a b c d e f g i j k r x y z
根据LCS算法(这个算法貌似很复杂，这里略掉了)，得到其最长公共子序列(LCS)是：
       LCS: a b c d f g j z
示意图如下：

（这个示意图是不严谨的，因为LCS是有顺序的，而集合却没有顺序性）

根据这个序列，就可以得到S2串和S1串间的差异：
如果某个字符S1中有，LCS中没有，表示S2中删除了这个字符，如上图的‘h’；
如果S2中有，而LCS中没有，则表示S2中增加了这个字符，如上图的“e,I,k,r,x,y”。
其结果如下：
       e  h  i  q  k  r  x   y
       +  -  +  -  +  +  +  +
这个结果就是diff比较后输出的差异文件。

这里diff的是字符串，实际的diff以"行"为单位来比较两个文本文件的。


如何读diff文件格式：

diff文件格式有列举模式，命令模式和上下文模式。

命令模式表示从原文件到新文件需要执行哪些命令才能实现。命令主要就是add,change,del。
命令模式可能主要便于程序自动执行的，人不太好读。

上下文模式则是由区块(chunk)组成的，区块列举原文件和新文件中有不同的地方，因为有上下文，所以更便于阅读。

看上下文模式的：

比如如下两个文件：


其diff的结果文件，上下文格式如下(部分结果)：


最开始的两行表示了这个diff文件是哪两个文件间的差异。
@@表示一个区块的开始，这个区块到下一个“@@”为止。


@@ -1,3 +1,9 @@
+This is an important
+notice! It should
+therefore be located at
+the beginning of this
+document!
+
This part of the
document has stayed the
same from version to
-1,3表示原文件的第1行到第3行间；
+1，9表示新文件的第1行到第9行
第3行和第9行，这两个行数不同，表示从源文件到新文件增加了几行。
带加号(+)的行，表示增加的，不带号的，表示原来就有的；

@@ -5,16 +11,10 @@
be shown if it doesn't
change.  Otherwise, that
would not be helping to
-compress the size of the
-changes.
-
-This paragraph contains
-text that is outdated.
-It will be deleted in the
-near future.
+compress anything.

It is important to spell
-check this dokument. On
+check this document. On

带减号(-)的，表示删除了这几行。
其余同上。

介绍完毕。

评论

3 楼 337240552 2013-03-10  

http://www.ruanyifeng.com/ 这个好理解

2 楼 tonytony3 2012-06-07  

thanks

1 楼 zhuxixi327 2010-10-28  

补充
下面的转自某处，但不记得了：
我之前曾经在一个帖子中回复了这个问题，但是找了一圈没找到。。干脆重敲一遍吧。。

svnbook中给出的场景描述大致是这样，当你修改完bug的时候，
不确定这次修改会不会通过测试，但又不想因为这个尚未测试通过的修改影响主干代码，
所以在修改完成后不提交——改用创建补丁功能将这个版本变化打成一个Patch文件，
提交测试，测试接到这个Patch后可以打在检出的代码上。测试通过后，
开发人员在工作副本中执行Patch，提交。主干保持稳定~

从我个人理解来看，SVN的开发团队比较注重其它配置管理工具优势功能的融合。
单就合并修补bug的代码这一活动，可以用锁（VSS特性）、分枝（CVS特性）、
创建补丁（不知道是谁家特性）。从VSS、CVS移植来的开发人员，都可以很快习惯SVN。
另外，用补丁功能，可以保持配置库内的洁净度（提交次数减少、无效提交次数减少），
可以回避分枝的创建和合并（谁合并代码谁头疼），可以方便版本回溯
（测试不通过就不打补丁提交，不用退回版本）。

暂时想到这么多