今天完成的内容：
（1）项目包命名规范。
 indi：
         个体项目，指个人发起，但非自己独自完成的项目，可公开或私有项目，copyright主要属于发起者。
         包名为“indi.发起者名.项目名.模块名.……”。
pers：
         个人项目，指个人发起，独自完成，可分享的项目，copyright主要属于个人。
         包名为“pers.个人名.项目名.模块名.……”。
priv：
         私有项目，指个人发起，独自完成，非公开的私人使用的项目，copyright属于个人。
         包名为“priv.个人名.项目名.模块名.……”
onem：
         与“indi”相同，推荐使用“indi”。
另外，我为了区分团队项目和前面所说项目的区分，还有了一下扩展：
team：
         团队项目，指由团队发起，并由该团队开发的项目，copyright属于该团队所有。
         包名为“team.团队名.项目名.模块名.……”。
com：
 公司项目，company缩写，copyright由项目发起的公司所有。
         包名为“com.公司名.项目名.模块名.……”。

（2）学习svn，复盘需要规范使用。

修真院svn目录：

比如：

task 为java官网task，task-html 为web官网task，carrots 为java萝卜多，carrots-html 为web萝卜多前台，

carrots-admin-html 为web萝卜多后台，还有玩在学习，聚金融等。

Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是：

svn://proj/

+-trunk

+-branches

+-tags

trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。

一般的，开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk 进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正，标准的开发流程如下：

（1）1.0开发完毕，代码冻结

基于已经冻结的trunk，为release1.0打tag

此时的目录结构为

svn://proj/

+trunk/ (freeze)

+branches/

+tags/

    +tag_release_1.0　(copy from trunk)

（2）2.0 开始开发，trunk此时为2.0的开发版

发现1.0有bug，需要修改，基于1.0的tag做branch

此时的目录结构 为

svn://proj/

+trunk/ ( dev 2.0 )

+branches/

     +dev_1.0_bugfix (copy from tag/release_1.0)

+tags/

     +release_1.0　(copy from trunk)

（3）在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发

（4）在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等

（5）根据需要选择性的把 dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）

明天的计划：先看项目吧，把项目定下，基础再说。

遇到的问题：暂无。

收获：以上