软件配置管理的一些基本概念
一点配置管理的使用心得，不保证正确，如果错了不要打我
，我闪先
……
转载请注明出处。
下文中VSS代表Microsoft的配置管理工具Visual Source Safe，CVS代表开源的配置管理工具Concurrent Version System。
1.源程序的签入和签出（Check in and Check out）
文件的签出(Check out)是指从配置管理系统的文件库中取出一个副本作为自己的工作拷贝，并在这个工作拷贝上进行自己的工作。
文件的签入(Check in)是指将自己的工作拷贝提交到配置管理系统的文件库中，使得他人可以从文件库中获取你的最新修改版本。
对于源程序的控制管理有两种方式，分别以VSS和CVS为代表
VSS使用的是“Lock-Modify-Unlock”的方式，即一个文件在同一时刻只能由一个人在进行修改；当某个人将文件签出后，该文件即被锁定，其他人即不能再对文件进行修改，其它人要进行修改只能等待签出人将文件修改完成，签入该文件解除锁定后才可以将该文件签出进行修改。
这种方式的好处就是可以防止由于多人同时修改一个文件导致互相覆盖，某些改变丢失；但是对于协同工作不利；
在绝大多数开源软件的开发中，对源代码的控制管理采取的是CVS，CVS的管理方式是“Copy-Modify-Merge”，在这种方式下，对于同一个源文件可以多人同时进行修改，修改后在提交时如果发现已经有他人的修改提交到了版本库中，系统将自动对多人所进行的修改进行合并；如果有两个人同时修改了同一个源文件的同一行，这时系统会提示发生冲突（Conflict），需要对该行进行修改的人进行交流，确定应该如何进行修改。
CVS也支持“Lock-Modify-Unlock”方式，但是不建议采用这种方式进行管理；VSS不支持“Copy-Modify-Merge”方式。
不论是哪一种方式，都应该保证以下两点：
1.提交到配置管理系统中的源文件是一个已经通过了单元测试的版本，不应该把未完成的或者未经过单元测试的版本提交到配置管理系统中，这样可以保证不论何时我们都可以从配置管理系统中提取出一个可以通过编译的版本。
2.在提交到配置管理系统中的时候，应该以简短的注释说明在这次提交中所做的修改；虽然我们可以通过对前后版本的比较查看所做的修改，但是修改者对修改所做的注释显然会有助于其他人对你的源代码的理解。
2.文件版本
文件的版本和项目的版本是不同的，对于文件来说，每次修改后提交都会产生一个新的版本，从版本控制系统中可以找到从文件创建到最后一次提交的每一个版本，对于文本格式的文件，通过一些比较工具（版本控制系统中的或第三方的）可以比较每一个版本之间的不同。
3.版本标签（Tag）
版本标签可以理解为对项目中所有文件在某个时刻的一个“快照”，和文件版本不同，项目的版本不是在每一次提交文件的时候产生的，项目版本需要我们手工创建。
比如，当所有模块都已经通过了单元测试，需要组合在一起进行集成测试时，可以对项目创建一个v1_0_Beta1的标签，标明当前项目开发进行到了一个阶段性目标；
此后可以类似的建立v1_0_Beta2、v1_0_Beta3等等标签，标识项目的开发进度；
当v1.0的Beta测试阶段完成后，需要发布v1.0正式版时，则建立v1_0_Final标签，以此标签时的源文件内容发布正式版本；
在建立了标签后，我们可以在任何时刻获取建立标签的时刻的项目中各文件的内容，这在实际开发中有很重要的作用，比如在查找Bug的时候，我们可以找到各个标签版本的程序，检查Bug是在哪一个版本中引入的，通过比较两个版本的内容，可以很快找出产生Bug的原因。
在VSS中，标签被称作Label，实际的意义是一样的。
需要注意的是，标签的设定并不一定要以所有文件的最新版本为准，我们可以以文件的任意版本组合成为一个版本标签，当然，这个版本是否是正确的甚至是否是可以通过编译的都需要自己控制，配置管理系统是不负责这个工作的。
4.分支（Branch）
分支是一种特殊的版本形式，我们可以对文件或项目分出一个并行开发的版本，对这个并行开发的版本进行修改，然后将分支版本的修改合并到主干上来。
分支的使用情况举例：
1.在项目开发中有一些想法，需要在当前项目上进行试验，如果直接在当前项目上进行试验，则不成功的话会在版本控制中留下错误的代码，如果对项目的试验以不在配置管理控制下的方式进行，则无法对开发过程进行记录，失去了配置管理控制的意义。
这种情况下，我们可以在当前的主干版本上建立一个分支，在分支上进行开发试验，如果成功，则可以把分支中的代码直接合并到当前主干版本上来，如果试验失败，则直接关闭分支即可，不会对主干版本的开发造成影响；
2.项目已经发布了v1.0版本，现在正在进行v2.0的开发，这时客户报告了非常严重的Bug，需要立即修改，这个时候我们可以从v1.0中生成一个分支版本v1.0.1，在这个分支版本中修改Bug，并把修改Bug后的v1.0.1版本发布给用户，v1.0.1版本对Bug的修改可以合并到v2.0中，这样对于一个Bug的修改我们只需要进行一次即可，不需要对多个版本分开维护，避免了各个版本的不一致
CVS对分支版本的控制非常完善，VSS也提供了对分支的支持，我没有使用过，但是实际据网上的一些反应来看，VSS的分支功能比较弱。
一点配置管理的使用心得，不保证正确，如果错了不要打我
，我闪先…… 转载请注明出处。
下文中VSS代表Microsoft的配置管理工具Visual Source Safe，CVS代表开源的配置管理工具Concurrent Version System。
1.源程序的签入和签出（Check in and Check out）
文件的签出(Check out)是指从配置管理系统的文件库中取出一个副本作为自己的工作拷贝，并在这个工作拷贝上进行自己的工作。
文件的签入(Check in)是指将自己的工作拷贝提交到配置管理系统的文件库中，使得他人可以从文件库中获取你的最新修改版本。
对于源程序的控制管理有两种方式，分别以VSS和CVS为代表
VSS使用的是“Lock-Modify-Unlock”的方式，即一个文件在同一时刻只能由一个人在进行修改；当某个人将文件签出后，该文件即被锁定，其他人即不能再对文件进行修改，其它人要进行修改只能等待签出人将文件修改完成，签入该文件解除锁定后才可以将该文件签出进行修改。
这种方式的好处就是可以防止由于多人同时修改一个文件导致互相覆盖，某些改变丢失；但是对于协同工作不利；
在绝大多数开源软件的开发中，对源代码的控制管理采取的是CVS，CVS的管理方式是“Copy-Modify-Merge”，在这种方式下，对于同一个源文件可以多人同时进行修改，修改后在提交时如果发现已经有他人的修改提交到了版本库中，系统将自动对多人所进行的修改进行合并；如果有两个人同时修改了同一个源文件的同一行，这时系统会提示发生冲突（Conflict），需要对该行进行修改的人进行交流，确定应该如何进行修改。
CVS也支持“Lock-Modify-Unlock”方式，但是不建议采用这种方式进行管理；VSS不支持“Copy-Modify-Merge”方式。
不论是哪一种方式，都应该保证以下两点：
1.提交到配置管理系统中的源文件是一个已经通过了单元测试的版本，不应该把未完成的或者未经过单元测试的版本提交到配置管理系统中，这样可以保证不论何时我们都可以从配置管理系统中提取出一个可以通过编译的版本。
2.在提交到配置管理系统中的时候，应该以简短的注释说明在这次提交中所做的修改；虽然我们可以通过对前后版本的比较查看所做的修改，但是修改者对修改所做的注释显然会有助于其他人对你的源代码的理解。
2.文件版本
文件的版本和项目的版本是不同的，对于文件来说，每次修改后提交都会产生一个新的版本，从版本控制系统中可以找到从文件创建到最后一次提交的每一个版本，对于文本格式的文件，通过一些比较工具（版本控制系统中的或第三方的）可以比较每一个版本之间的不同。
3.版本标签（Tag）
版本标签可以理解为对项目中所有文件在某个时刻的一个“快照”，和文件版本不同，项目的版本不是在每一次提交文件的时候产生的，项目版本需要我们手工创建。
比如，当所有模块都已经通过了单元测试，需要组合在一起进行集成测试时，可以对项目创建一个v1_0_Beta1的标签，标明当前项目开发进行到了一个阶段性目标；
此后可以类似的建立v1_0_Beta2、v1_0_Beta3等等标签，标识项目的开发进度；
当v1.0的Beta测试阶段完成后，需要发布v1.0正式版时，则建立v1_0_Final标签，以此标签时的源文件内容发布正式版本；
在建立了标签后，我们可以在任何时刻获取建立标签的时刻的项目中各文件的内容，这在实际开发中有很重要的作用，比如在查找Bug的时候，我们可以找到各个标签版本的程序，检查Bug是在哪一个版本中引入的，通过比较两个版本的内容，可以很快找出产生Bug的原因。
在VSS中，标签被称作Label，实际的意义是一样的。
需要注意的是，标签的设定并不一定要以所有文件的最新版本为准，我们可以以文件的任意版本组合成为一个版本标签，当然，这个版本是否是正确的甚至是否是可以通过编译的都需要自己控制，配置管理系统是不负责这个工作的。
4.分支（Branch）
分支是一种特殊的版本形式，我们可以对文件或项目分出一个并行开发的版本，对这个并行开发的版本进行修改，然后将分支版本的修改合并到主干上来。
分支的使用情况举例：
1.在项目开发中有一些想法，需要在当前项目上进行试验，如果直接在当前项目上进行试验，则不成功的话会在版本控制中留下错误的代码，如果对项目的试验以不在配置管理控制下的方式进行，则无法对开发过程进行记录，失去了配置管理控制的意义。
这种情况下，我们可以在当前的主干版本上建立一个分支，在分支上进行开发试验，如果成功，则可以把分支中的代码直接合并到当前主干版本上来，如果试验失败，则直接关闭分支即可，不会对主干版本的开发造成影响；
2.项目已经发布了v1.0版本，现在正在进行v2.0的开发，这时客户报告了非常严重的Bug，需要立即修改，这个时候我们可以从v1.0中生成一个分支版本v1.0.1，在这个分支版本中修改Bug，并把修改Bug后的v1.0.1版本发布给用户，v1.0.1版本对Bug的修改可以合并到v2.0中，这样对于一个Bug的修改我们只需要进行一次即可，不需要对多个版本分开维护，避免了各个版本的不一致
CVS对分支版本的控制非常完善，VSS也提供了对分支的支持，我没有使用过，但是实际据网上的一些反应来看，VSS的分支功能比较弱。
