SVN 多人修改，如何管理 关于版本的问题
从问题描述可以看出，这是采用配置管理工具（代码版本控制工具）初期比较典型的问题，要解决此问题需要做以下调整：
- 采用成熟的主干-分支代码管理方法；
- 需要指定专职或兼职的人员来负责代码规划和管理，包括分支的创建和合并，通常称为配置管理员（CMO）；
先简单介绍一下主干-分支代码管理方法：
- 代码库中创建三个目录：trunk、branches和tags，分别存放稳定代码、开发代码和用于生产环境的可发布代码；
- Branches中可以有多个分支，可以按人员、用途或版本划分，具体视公司情况而定。
- 通常把项目初始项目结构创建好，由CMO提交到trunk，CMO再基于trunk创建规划好的分支。
可行的解决方案：
- CMO创建以下初始目录结构
Trunk
Branches
----dev
----test
Tags
- 开发人员基于trunk创建个人开发分支到dev目录下，进行个人的开发，将代码部署到开发环境中，每天将通过单元测试的代码提交到此分支。
- 测试人员将dev目录下某个或某些开发人员的开发分支合并到test的某个子分支下，将代码部署到功能测试环境，进行集成或系统测试。
- 性能测试人员将test目录下通过集成或系统测试后的代码部署到性能测试环境，进行性能 测试。
- CMO将test目录下通过性能测试的代码合并到trunk。
- 当发布计划中的功能都已就绪，产品发布人员可以将trunk中的代码部署到生产预热环境中进行试运行。
- 试运行没有发现问题，CMO将trunk代码创建一个正式的发布分支到tags中，可以用版本号命名。
- 产品发布人员将tags中最新版本代码部署到生产环境中。
- 随着时间的推移，配置库的目录可能的结构如下所示。
Trunk
Branches
----dev
----------john
----------tom
----------…
----test
---------test-20120901
---------test-20121001
---------test-20121101
---------test-…
Tags
----release v 0.0.1
----release v 0.1.0
----release v 0.2.0
----release …
最后，由于需要频繁的用到合并操作，就不可避免的遇到代码冲突。发生冲突时需要由相关的代码作者来一起讨论解决。根据以往的经验，可能通过以下方式来减少冲突发生的机会：
- 功能尽可能的模块化，一个功能不应涉及到两个或多个模块的修改。
- 不在代码库中保存项目的中间文件、临时文件或因人而异的配置文件。
- 做好写权限管理，避免不必要的误修改操作。