SVN版本控制

先来说几个名词的含义吧：版本库：repository主线：trunk分支：branch标签：tag检入：check in 检出：check out 基线:被完整标记出来的，具有整体的完整代码的版本trunk：是用来做主方向开发的，一个新模块的开发，这个时候就放在trunk，当模块开发完成后，需要修改，就用branch。

branch：是用来做并行开发的，这里的并行是指和trunk进行比较。
tag：是用来做一个milestone的，不管是不是发布版本，但都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读的标记。

由于公司刚成立不久，对版本控制竟然是完全手工的。哎，看着就揪心，万一哪天出事故，估计要哭死！但是大家现在好像都在坐以待毙，我知道大家都是觉得用一个新工具上手比较难，所以好像得过且过吧，还有一个重要的原因就是，我们公司管理制度没有搞起来。要让大家组织培训吧也不行，所以现在要让大家心甘情愿的弄确实难度很大。在大家都反对的情况下，想过放弃了吧。但是心里还是强烈的想把它做起来。下面就来说说我的心得。软件的配置与管理，权威的定义太多高大上，根本看不懂，大家可以试试看看：

我觉得只要是正常人都看不明白，云里雾里的。
呵呵，在这里我就要说我理解的配置管理了。其实也是偷拿别人的理解啦。
软件配置管理既是：软件的资产管理：
1、软件历史版本的记录
2、修改的原因，谁修改的，这些记录必须有，以便后来的维护
3、两个人同时修改文件，防止版本的覆盖问题
可以形象的比喻为：保险柜、岩钉、脚印。请大家仔细体会这几个词与软件版本控制之间的关系。
svn版本控制的原理就是，找个大的公共储存区，保证，每次提交前去公共区里拿到最新的代码，每个人拿到最新的代码去提交，这样就不会导致版本不一致问题。当然如果修改的是同一行代码，这时候就会有冲突，需要人工去解决。
解决充的方法有两种：
1 串行锁模式

2、并行复制修改合并模式，每个程序员都可以先拷贝一个副本在自己本地进行开发修改，最后进行商量合并。
这两种模式都有自己的适用范围：
锁模式适用于哪些不能合并的元素，例如图片元素。
复制修改合并模式适用于代码等可以合并操作的元素。

任务单元-活动-变更集
以上三点都是一个概念就是指同一个意思，为什么要说任务单元呢？
其实这里就是我们要说的项目提交粒度问题，我们将一个大任务分成很多小任务，这样的小任务一旦完成，并做好了相应的 测试，那么此时就可以检入操作。这样的检入操作既保证后期能够及时的合并，（因为开发时间越长，合并的难度就越大），也可以防止没有完成的提交导致编不能通过的问题。
下面我们来说一下版本号的命名：
版本号一般分为：主版本号、特征版本号、BUG修复版本号。
主版本号标志着产品的第几代，特征版本号表示新叠加的功能，bug修复版本号很显然就是每次版本的bug修复编号。bug修复编号也标志着产品质量的提升。
一个号的命名规则可以使我们更好的找到对应的版本。
系统集成：就是将开发好的各个开发好的模块组织起来，完成一个能运行的整体。
系统集成看起来是开发好模块后完成，但是在实际的研发中不是这样的，你想像一下这个场景，A、B、C各开发好了一个功能，他们都能在自己的环境下运行，但是他们不知道的是他们之间修改的代码有很多交叉，这样合并集成的难度就会非常大，所以在适时的集成就非常重要了。也许是打好了框架，也许是完成了雏形就可以进行集成了。

及早、经常、持续集成：

持续更新中。。。。。