前提：代码仓库的管理均会采用svn来管理
代码目录结构的创建：
一般创建三个目录为：
-- trunk（主干）
-- tags（标签/标记）
--branches（分支）
有时在同级目录下还会创建一个wiki的目录，作为对项目的介绍等。我有时也叫tags目录为里程碑文件夹，会把里程碑版本放在此处。
tags和branches下一般为根据需要从trunk目录拷贝过来的。
tags的创建要求：
1、代码在一种平台下通过编译（必须）；
2、代码编译出来的版本通过一定冒烟测试、单元测试；
3、在项目要求的平台都可以编译通过；
4、一般有一个测试包提交测试时，就需要在tags下建立对应代码标签。
tags下的代码一般不可以修改。
掌握创建分支的时机
这是一个容易引起争议的问题，事实上它取决于您的软件项目培养。没有规定通用的策略，仅在此描述三种常见的。
从不分支系统
（常用于还没有可运行代码的初始项目。）
- 用户将他们的日常工作提交到 /trunk 中。
- 用户开始提交一系列复杂更改时，/trunk 偶尔会“损坏”（无法进行编译或功能测试失败）。
优点：此策略非常容易遵守。新开发人员进入的门槛很低。不需要学习如何进行分支或合并。
缺点：无序的开发和代码可能随时变得不稳定。
旁注：在 Subversion 中，此类开发的风险要比在 CVS 中小得多。因为 Subversion 的提交是封闭单元式的，因而在其他人的提交过程中，签出或更新不会收到“部分”提交。
始终分支系统
（常用于需要进行大量管理和监督的项目。）
- 每个用户对每项 编码任务的创建或操作都是在私有分支中进行的。
- 编码完成后，原编码者、同级或经理将对所有私有分支的更改进行审查并将它们合并到 /trunk 中。
优点： 能保证 /trunk 始终都能极其 稳定。
缺点：编码者之间被人为隔离，会导致很多不必要的合并冲突。需要用户进行大量的额外合并工作。
按需分支系统
（这是 Subversion 项目所使用的系统。）
- 用户将他们的日常工作提交到 /trunk 中。
- 规则 #1：必须随时对 /trunk 进行编译并确保通过回归测试。将对违反此规则的提交者提出公开批评。
- 规则 #2：单个提交（更改集）必须小于同级所能审查的最大限度。
- 规则 #3：如果规则 #1 与 #2 产生冲突（如一系列小提交必然会扰乱 trunk），则用户应创建分支，然后将一系列更小的更改集提交到分支中。这样即可允许进行同级审查，又会不破坏 /trunk的稳定性。
优点： 可保证 /trunk 始终都能保持稳定。分支和合并的问题将较少。
缺点：将添加一些负担到用户的日常工作中：每次进行提交之前，都必须进行编译和测试。
里程碑的创建
集成人员将开发人员提交的功能集成到主干上，编译通过后提交到主干上集成了一定的功能后，创建一个里程碑版本，一般建议按周创建里程碑版本。并在tags下创建响应的代码快照，并将安装包传至指定位置。
开发人员一般于最新的里程碑版本创建分支，并在分支上工作，并在自己的分支上提交，在提交到svn之前需要编译通过。开发人员需要根据自己开发情况来同步到主干的里程碑代码。如果需要继承主干上，需要同步到新近的里程碑。
测试人员
测试人员对开发人员的代码进行测试，达到一定测试标准后，测试通过，然后提交由集成人员来集成。按需分支系统适应方式代码较少，或者参与开发人员较少
开发人员可以直接主干上提交。开发负责人来编译版本给测试。
开发人员把所有的新特性提交到主干，每日的修改提交 /trunk，新特性， bug修正和其他。新近的开发人员不能提交代码，交由有经验的开发人员验证后才能提交到主干上。
当开发小组认为软件已经做好基本发布的准备（比如，版本1.0）然后 /trunk 会拷贝到 /branches/1.0。这个主干被拷贝到“发布”分支。然后再发布分支上继续修改bug。
如果bug修正经测试达到一定的要求认为可以完成时，可以拷贝到/tags/1.0.0，这个标签被建立并放权给相关人员
向svn库提交代码要求针对每次提交到主干上的代码均需要编译通过，代码每次提交到svn上均需要添加注释。
这是本人查看文档和自己实践后的总结，有错误的地方或更好的方法，还希望大家提出。
以前只是看别人写的文章，看懂后只是实践下就收藏起来，结果后来在用的时候发现很多好的文章都找不到了，所以以后会经常做总结和学习记录。