从工作至今，一直使用 SVN管理软件版本。其中碰到的一些问题和坑，分享一下。
存在的现象，
1）提交版本的说明一般是简短的一句话，例：修复bug，增加某某功能。
究竟修改了什么bug，增加了什么功能
2）模块完成后，提交移植模块的代码到主干版本上面。
大型模块代码的移植可能需要几天、周。
其中模块依赖的变量，逻辑可能变化。
模块本身也需要存档。
3）多人对同一个工程的代码管理，公共部分代码修改未全部通知搭档
公共部分代码的修改，代码上传需要review，确保相关同事的代码、逻辑不受影响，防止新bug引入。
4）SVN down 下来的代码需要额外的去配置，寻找项目依赖的库文件
目标：SVN down下来的代码是可编译的，对应依赖库的版本同步上传。
使用心得：
1）单一功能增加应该提交SVN。
理想状态
2）SVN 提交日志详细描述。
例：【bug】修复某某bug，修改某某东西....。【功能】新增某某模块的某某。【版本 V1.0.0.0】版本号对应的相应版本的代码。
3）不擅自修改责任模块之外的代码。
碰到模块之外的bug，更好的idea，和同事讨论改之，如果是公共代码，告知所有可能使用它的同事。
4）发布的稳定版本很可能不是SVN最新的版本。
稳定软件版本的代码是落后于最新的SVN版本。新增的代码、功能需要测试后，变成发布的稳定版本。
版本定位：1，对应的版本号。在svn 上拉出发布的版本，（更希望的方式）
2，对发布的版本单独进行提交，且说明。（仅仅跟踪作用）
所有开发人员统一思想，去维护SVN代码。避免局部个人的代码影响整个软件。