1.create patch
使用create patch可以生成一个或者多个修改过的文件和当前版本差异的patch（支持目录树）
通常情况下，create patch将修改保存为.patch或.diff文件
可以将.patch或.diff文件的内容复制出来，发给需要审查的人
.patch或.diff文件中记录了发生这个patch的版本号以及具体修改的内容
针对某个文件或某几个文件的若干种修改，可以生成多个.patch或.diff文件
2.apply patch
可以将.patch或.diff文件应用到对应版本的项目，就像打补丁一样
同一个项目/文件夹下，可以选择应用需要的patch
通常来说，应用一个patch时文件版本和生成这个patch时文件的版本是一致的；如果不一致，也可以强制应用，svn会自动进行diff（这时候需要手动合并）
linux下，可以使用系统的patch命令来应用patch，eg: patch -p0 <xxx.patch
3.使用
暂时不需要提交或不允许提交的修改，可以选择create patch来保存修改的内容
选择create patch来保存修改的内容并且提交patch，通过审查后，(在服务器端)应用patch
当一个功能有多种解决方案时，可以生成多个patch，（提交后）分别经过测试，再决定应用哪个patch
多个功能分别需要改同一个文件的不同地方（即没有同一行），可以做成多个patch，应用patch的顺序没有要求（在linux下应用也一样成功，只是会生成多个.orig文件）
多个连续性的功能，他们修改的文件都与一个base作patch，例：p1在v1的基础上开发v2，生成v2和v1之间的patch1；p2在v2的基础上开发v3，生成v3和v1之间的patch2，这样只要应用patch2也就应用了patch1。
4.带来的问题
一个较早的patch，在经过多轮提交后，如果想再要应用，需要严格的diff
如果两个patch分别改了同一行代码，应用第一个patch后要再应用第二个patch时，仍然需要diff。如果在linux下，会产生冲突，生成.orig和.rej两个文件（此时仍然需要手动进行比较合并）
第3部分提到的连续性，要准确的预见到，比较困难
第3部分提到的多个连续的功能，后做的功能的某个文件更新了先做的功能的内容，但先做的功能可能还涉及到其他文件，容易造成漏更新文件的情况
使用create patch可以生成一个或者多个修改过的文件和当前版本差异的patch（支持目录树）
通常情况下，create patch将修改保存为.patch或.diff文件
可以将.patch或.diff文件的内容复制出来，发给需要审查的人
.patch或.diff文件中记录了发生这个patch的版本号以及具体修改的内容
针对某个文件或某几个文件的若干种修改，可以生成多个.patch或.diff文件
2.apply patch
可以将.patch或.diff文件应用到对应版本的项目，就像打补丁一样
同一个项目/文件夹下，可以选择应用需要的patch
通常来说，应用一个patch时文件版本和生成这个patch时文件的版本是一致的；如果不一致，也可以强制应用，svn会自动进行diff（这时候需要手动合并）
linux下，可以使用系统的patch命令来应用patch，eg: patch -p0 <xxx.patch
3.使用
暂时不需要提交或不允许提交的修改，可以选择create patch来保存修改的内容
选择create patch来保存修改的内容并且提交patch，通过审查后，(在服务器端)应用patch
当一个功能有多种解决方案时，可以生成多个patch，（提交后）分别经过测试，再决定应用哪个patch
多个功能分别需要改同一个文件的不同地方（即没有同一行），可以做成多个patch，应用patch的顺序没有要求（在linux下应用也一样成功，只是会生成多个.orig文件）
多个连续性的功能，他们修改的文件都与一个base作patch，例：p1在v1的基础上开发v2，生成v2和v1之间的patch1；p2在v2的基础上开发v3，生成v3和v1之间的patch2，这样只要应用patch2也就应用了patch1。
4.带来的问题
一个较早的patch，在经过多轮提交后，如果想再要应用，需要严格的diff
如果两个patch分别改了同一行代码，应用第一个patch后要再应用第二个patch时，仍然需要diff。如果在linux下，会产生冲突，生成.orig和.rej两个文件（此时仍然需要手动进行比较合并）
第3部分提到的连续性，要准确的预见到，比较困难
第3部分提到的多个连续的功能，后做的功能的某个文件更新了先做的功能的内容，但先做的功能可能还涉及到其他文件，容易造成漏更新文件的情况