都讲的很详细啊，每个公司的要求不一样，控制管理也就会不一样，不过总休都是按CMMI过程进行管理控制的，我是按下图方式建立三库的。

trunk:工作目录库，里面创建其他的需求工作目录，源文档、源代码就放入到这个库里进行版本控制。
tags:受控库，只有SCM才有权限读写，其他人员只有通过Web浏览查看里面的文件。
branches:基线库，也只有SCM有权限读写。

[ 本帖最后由 yjg021 于 2007-8-19 14:27 编辑 ]

引用:

原帖由 yjg021 于 2007-8-19 14:23 发表
...
branches:基线库，也只有SCM有权限读写。
...

建议你还是改一下“branches”这个名字吧，容易让人产生误会。SVN-book 建议大家建立branches目录的目的可不是这样用的。这个主要是工程项目的分支。

目录的用法，我觉得与公司的实际情况关系比较大。

照办别人的办法未必好。

俺倒是希望大家都贴出自己的目录，供俺借鉴一下

其实你应该将你们公司的控制流程和配置库结构结合起来考虑，并不一定需要体现出三类库，配置管理不单单是文件管理员，重要的还是流程，好的流程即使没有VSS、SVN等等配置管理工具，但用Window也可以建立配制管理平台的。
      建议你结合你们公司的流程思考，各文档各类库的流转。


本人也是菜鸟一个，说说自己想法而已，说错了，别骂我

同意，其实看多了人家的目录结构可能最后还是没主意，还是应该结合公司和项目的实际情况

非常关注这样的帖子！！！

关于这个配置库的目录结构一直很困惑~~

对你使用的工具了解不多，但是
不建议物理方式区分开发、受控、基线库，建议梳理三库的配置项组织结构，保持一致，在使用同一份（集合）配置项为基准，创建不同的版本分支（ClearCase中称为UCM项目、流），不同的流用于不同的作用（开发、集成、发布等），开发完成后可以同步到集成、集成并测试后，可以同步到发布流。即，保证配置项的唯一性，区分流完成不同的工作目标，通过流之间的版本同步来标识配置项版本的流转（提交），由于基于唯一性，就可以对版本进行对比、差异分析等（这点如果使用不同物理库，无法达到）。

概念交流，学习ing

一个单元里的房子，每层装修的都不一样，各家也都认为自己的是最合适的。

配置库也一样。