svn合并不同树_爱的初体验之-尝试MATLAB自带SVN（上）

经历过一个赛季，对于源代码管理和版本控制也有了一些自己的想法，特别是在了解到一些车队已经在使用SVN之后。回顾上个赛季，在没有做好源代码管理的情况下确实遇到了一些切切实实的痛点，来驱使我去探索MATLAB自带的SVN，以及写这篇笔记做记录。

其实将源代码管理简单地应用到实际的开发过程中，是不存在技术难度的。主要问题在于没有源代码管理，或者版本控制的概念，所以这篇文章的上半部分是在讨论源代码管理能给我们带来什么。

对于下面几种类型的项目，确实不需要用到源代码管理：

1、个人项目

2、由一人完成大部分工作，其他人做一些简单的优化、维护，且成员互相之间的工作在时间、内容上相互关联、依赖的部分非常少

3、迭代优化的次数和频率都很低的项目。

这些项目只需要简单的以日期命名，或以其他常见命名方法来区分不同的版本就行了。

但当我遇到下面的情况时：

此前遇到的问题

A、B、C三人共同参与一个项目

A负责开发一个Simulink物理模型，从开始建模到最终完工预计需要十个月。而在此过程中，A在一边建模、验证、优化、维护的同时，一边要把每次修改完的版本提供给B。B在Simulink中开发控制算法，并在A的模型上进行算法的仿真、迭代优化。同时A还会把模型提供给C，让C做一些仿真与分析的应用。

由于搭建模型的工作量相当之大，尤其是不断的优化和验证（这些工作是必要而又十分耗时耗力的），A所做的模型的更新频率十分之高，甚至于一天之内会修改两到三版，以至于十个月下来，大改小改之后的各类版本总数可能接近三位数。更加要命的是，如果是细微的优化修改还好，如果是大改，以至于B、C也需要针对新版本对自己的工作进行大改，且B、C之间的工作也是相互紧密联系的，这场三角恋就成了噩梦。

某天，A在对旧版本进行验证分析之后做出了进一步修改，其中有一处改动较大（譬如说对子系统S进行了大改）。随后以日期命名，比如命名为Model1.25，并修改了对应的说明文档，写明了对子系统S所进行的改动。然后打开微信，将所述模型和文档发送给B和C，不巧，文件太大只能登陆QQ，将所述模型和文档通过QQ发送给两个人。