03-项目SVN目录结构
svn常见结构
svn常见结构摘要：1.SVN 简介2.SVN 常见结构1.trunk2.branches3.tags4.revisions正文：1.SVN 简介SVN，全称Subversion，是一个开源的版本控制系统，用于管理代码和文档的修改和变更。
通过使用SVN，团队成员可以在协同工作中追踪和共享修改。
SVN 具有分布式特点，即可以在本地计算机上直接进行版本控制，而不需要网络连接。
2.SVN 常见结构SVN 中的常见结构包括：trunk、branches、tags 和revisions。
了解这些结构有助于更好地管理和协同工作。
1.trunktrunk 是SVN 中的主分支，用于存储项目的最新稳定版本。
当团队成员提交更新时，这些更新会首先添加到trunk 中。
trunk 是开发过程中的核心分支，也是发布新版本的基础。
2.branchesbranches 是用于存储项目不同版本的分支。
当团队成员需要开发一个新功能或者修复一个bug 时，可以从trunk 中创建一个新的分支。
这样，团队成员可以在新分支上进行开发，而不会影响到trunk 中的稳定版本。
分支完成后，可以将其合并回trunk。
3.tagstags 是用于标记项目特定版本的分支。
与branches 不同，tags 通常是只读的，这意味着团队成员不能在tags 上进行修改。
tags 可以帮助团队成员追踪项目的历史版本，并在需要时恢复到特定版本。
4.revisionsrevisions 是SVN 中的基本单元，用于记录每一次提交更新的详细信息。
每个revision 都有一个唯一的标识符，称为revision number。
通过revision number，团队成员可以追踪代码的变更历史，以及是谁在何时进行了哪些修改。
总之，SVN 的常见结构包括trunk、branches、tags 和revisions。
了解这些结构有助于更好地管理和协同工作。
svn 管理规范
svn 管理规范svn管理规范版本控制系统（Version Control System，简称VCS）是软件开发过程中非常重要的一环。
它可以帮助开发者管理和跟踪代码的变更，并且提供团队协作的平台。
其中，Subversion（简称svn）是一种常用的版本控制系统，本文将介绍svn的管理规范，以帮助团队更好地利用和维护代码库。
一、项目目录结构规范在svn中，良好的项目目录结构有助于提高代码的管理效率。
下面是一种常用的目录结构示例：/trunk：主开发分支，包含最新稳定版本的代码。
/branches：用于存放各个功能开发分支，每个分支对应一个特定的功能或任务。
/tags：用于存放各个版本的发布代码，每个版本对应一个标签。
除了上述目录外，可以根据具体项目的需求，在项目目录下添加适当的子目录，用于存放文档、配置文件等。
保持目录结构的一致性和规范性，有助于团队成员之间的协作和代码追溯。
二、提交日志规范在svn中，提交日志（Commit Log）是记录代码变更的重要信息，它对于维护代码历史、查找改动原因等都非常有价值。
因此，编写规范的提交日志是必要的。
以下是一些提交日志规范的建议：1. 简明扼要：提交日志应该简洁明了，能够快速传递变更的信息。
2. 描述变更内容：明确记录每次变更的具体内容，例如修复了某个bug、新增了某个功能等。
3. 引用相关事项：如果某次提交与特定的issue、需求或者任务相关，应该在提交日志中进行引用。
4. 避免无意义的提交：避免不必要的提交，例如空格调整、拼写错误修正等。
三、分支管理规范svn的分支功能可以帮助团队进行并行开发，不同功能模块可以在不同的分支上进行独立开发，最后再进行合并。
以下是一些建议的分支管理规范：1. 主分支保持稳定：将主分支（/trunk）保持稳定，只有经过测试和验证的代码才能合并至主分支。
2. 分支命名规范：分支命名应具备一定的可读性，可以采用功能模块的名称或者相关的任务、需求编号等。
SVN文档目录规则
| | | | |---Application //页面文件
| | | | |---<系统模块名1> //按照系统模块存放该系统模块的界面原型, 模块名称（中文）.rar
| | | | |---<系统模块名2> //按照系统模块存放该系统模块的界面原型
| | |---测试开发
| | |---V*.* //测试脚本
| | |---测试执行
| | |---V*.* //测试执行记录、测试报告、性能测试报告、测试评估报告、系统测试审核报告
| |----过程文档 //存放产品的管理文档
| |---项目管理 //项目管理类的文档
| | |---会议
| | | |---CCB会议 //存放CCB的预审报告和会议结果,存档管理
| | |---其他文档
| |---验收测试
| |----部署
| |---集成 //存放产品集成方案
| | |---V*.* //存放版本集成手册
| |---安装手册 //存放产品的安装手册、升级指导书
| | |---RP需求管理 //存放RequisitePro需求管理项目的.RQS文件
| |---设计 //总体设计类文档
| |---总体设计 //存放软件架构文档、技术预研性报告文档及论证报告文档
| | |---代码行统计 //存放代码行统计结果文件,存档管理
| |---其他
| | | |---<系统模块名2> //目录结构同上
| | |---界面原型 //如果是一个系统一个压缩包，则为系统名称（中文）.rar，直接存放在界面原型目录下即可
| | | |---BS //BS架构下用户界面文件
svn结构
SVN结构什么是SVN结构SVN（Subversion）是一个开源的版本控制系统，用于管理项目的源代码。
SVN结构是指在使用SVN进行版本控制时，项目中的文件和目录的组织方式。
SVN结构是一个层次化的结构，以便于团队成员协作开发和管理项目。
它包括仓库（Repository）、目录（Directory）、文件（File）等元素。
SVN结构的组成1. 仓库（Repository）仓库是SVN中最顶层的结构，它存储了项目的所有版本信息。
一个SVN仓库可以包含多个项目，每个项目都有一个唯一的根目录。
仓库是一个集中式的存储空间，团队成员可以通过SVN客户端从仓库中获取最新的代码，并将自己的修改提交到仓库。
2. 目录（Directory）目录是SVN仓库中的一个元素，它用于组织和管理文件。
目录可以包含子目录和文件。
在SVN结构中，目录可以表示项目的不同模块或功能，例如src目录存放源代码，doc目录存放文档，test目录存放测试代码等。
3. 文件（File）文件是SVN仓库中的一个元素，它存储了项目的具体内容。
文件可以是源代码文件、文档文件、配置文件等。
在SVN结构中，文件可以直接存放在目录中，也可以存放在子目录中。
SVN结构的最佳实践1. 分层结构为了方便管理和维护，SVN结构应该采用分层的方式组织。
可以按照功能、模块、团队等维度进行划分，每个层级对应一个目录。
例如，可以将项目按照功能划分为src目录（存放源代码）、doc目录（存放文档）、test目录（存放测试代码）等。
2. 规范命名为了方便团队成员理解和使用，SVN结构中的目录和文件应该使用规范的命名方式。
命名应该简洁明了，能够准确描述目录或文件的内容。
例如，可以使用英文单词或缩写作为目录和文件的名称，避免使用中文或复杂的命名方式。
3. 忽略不必要的文件在SVN结构中，有些文件是不需要进行版本控制的，例如编译生成的文件、临时文件等。
为了避免这些文件影响版本控制，可以将其添加到SVN的忽略列表中。
SVN目录介绍
一、SVN 版本库目录名称及含义
1.项目相关（说明：下表主要指 trunk 主线下的目录，branches 和 tags 目录不体现。）
一级 目录
Doc （文 档 类）
二级目录
PM （项目管理
类）
En （工程类）
三级/四级目录
中文名称
PP
项目策划
PMC
项目监控
IPM
集成项目管理
RSKM
风险管理
REQ M
Dev RD （开
TS 发类）
PI
VER
需求管理
需求开发 技术实现 产品集成 验证（评审）
VAL（测试类） 确认 （测试）
英语全称
Project Planing Project Monitor and Control Integrated Project Management Risk Management Requirements Management Requirements Development Technical Solution Product Integration Verification Validation
CM
Supp （支持类）
PPQA MA
DAR
SC （源 码 类）
其它
Prod （产品类）
暂无
．．． （由项目经
理添加）
暂无 暂无 暂无
配置管理
Configuration Management
过程与产品质量保 Process and Product Quality
证
Assurance
度量与分析
Measuremnet and Analysis
SVN目录结构设计方案
SVN目录结构设计目录1引言 (3)1.1软件概述 (3)2 目录结构规划 (3)2.1公司常用文档 (3)2.2软件开发相关文档模板 (3)2.3软件开发常用软件 (3)2.3.1 开发工具 (3)2.3.2 设计工具 (3)2.3.3 前台工具 (3)2.3.4 通用工具 (4)2.4软件项目 (4)2.4.1软件名称（客户名称） (4)2.5公司产品 (4)2.5.1产品名称 (4)1引言1.1软件概述基于目前的软件部情况，决定采用SVN公共管理平台，来解决一些公共文件的整合。
2 目录结构规划2.1公司常用文档软件开发相关文档模板中用来存放软件开发过程中常用的文档模板，包括软件需求分析模板、软件概要设计模板、软件详细设计模板、软件测试要点等。
2.2软件开发相关文档模板软件开发相关文档模板中用来存放软件开发过程中常用的文档模板，包括软件需求分析模板、软件概要设计模板、软件详细设计模板、软件测试要点等2.3软件开发常用软件2.3.1 开发工具软件开发常用的工具，包括vs2015、SqlSever等。
2.3.2 设计工具软件开发常用的工具，包括Axure、PowerDesigner等。
2.3.3 前台工具软件开发常用的工具，包括photoshop、Illustrator、flash开发工具等。
2.3.4 通用工具软件开发常用的工具，包括反编译软件、有道翻译、飞秋等。
2.4软件项目软件项目主要是公司准备或正在开发的软件项目，各项目以“软件名称（客户名称）”命名。
2.4.1软件名称（客户名称）项目启动后在软件项目下添加软件名称目录，用来管理整个项目。
该目录下又包括了软件相关文档、软件代码、其他相关。
2.4.1.1软件相关文档软件相关的文档，如软件需求分析文档、软件概要设计文档、原型等。
2.4.1.2软件代码软件相关的文档，如软件需求分析文档、软件概要设计文档等。
2.4.1.2其他相关软件相关一些图片、软件等。
SVN配置库及权限目录结构
R R R R R R R R R R R R R R R
R、C、A R R R R R R R R R R R R R R
R R R R R R R R R R R R R R R
R R R R R R R R R R R R R R R
R R R R R R R R R R R R R R R、C、A
权限说明
客户提供 的文件只 有可读权 限，不允 许有任何 修改，一 旦发生变 化需要客 户立刻刷 新文件 计划类文 档只有pm 和tc有修 改权限
评审类文 档所有人 人都有迁 入和迁出 权限
不同类型 的职位有 对应的权 限，其他 人有可读 权限
R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A R、C、A
0.2-Code
2.0-Tag 2.1-Trunk 2.2-Branch
2.3-compile 2.4-build 0.3-Tag 3.0-Supply 3.1-Prepare 3.2-Plan 3.3-SRS 3.4-Design 3.5-code/ST 3.6-SDV/Close 3.7-user profile 0.4-Release 4.0-code 4.1-user profile 3.1.0-Standard 3.1.1-RTM 3.2.0-integration planning 3.3.0-final drafts 3.4.0-Fi 3.4.1-Hi-fi 3.5.0-ST case 3.6.0-SDV Scheme 3.6.1-SDV case
R R R R R R R R R R R R R R R
SVN管理规范
SVN管理规范SVN（Subversion）是一种版本控制系统，用于管理和跟踪软件开辟过程中的代码变更。
为了确保团队成员之间的协作顺畅，提高代码管理的效率和质量，制定一套SVN管理规范是非常必要的。
本文将详细介绍SVN管理规范的标准格式，包括仓库结构、分支管理、提交规范、冲突解决等方面。
一、仓库结构SVN仓库是存储代码的地方，良好的仓库结构可以使代码的组织和查找更加方便。
通常，一个项目对应一个仓库，仓库下可以有多个项目。
1. 主仓库结构主仓库结构普通包括以下目录：- branches：用于存放项目的分支，每一个分支对应一个目录。
- tags：用于存放项目的标签，每一个标签对应一个目录。
- trunk：用于存放项目的主干代码。
2. 项目仓库结构项目仓库结构普通包括以下目录：- docs：用于存放项目相关的文档。
- src：用于存放项目的源代码。
- test：用于存放项目的测试代码。
- lib：用于存放项目的依赖库。
二、分支管理分支是SVN中重要的概念，它能够实现并行开辟和版本控制。
在项目开辟过程中，合理地使用分支可以提高团队的工作效率。
1. 分支创建创建分支时，应该遵循以下原则：- 从主干（trunk）创建分支。
- 分支名称应该具有描述性，能够清晰表达分支的目的和用途。
- 创建分支时，应该在分支目录下添加一个README文件，用于记录分支的相关信息。
2. 分支合并分支开辟完成后，需要将其合并回主干。
合并时，应该遵循以下原则：- 在合并前，需要先更新主干代码，确保与分支代码同步。
- 使用合适的合并策略，如合并所有变更、合并指定范围的变更等。
- 合并完成后，应该进行代码的冲突解决和测试，确保合并后的代码质量。
三、提交规范提交是将代码变更保存到SVN仓库中的操作，为了保证提交的质量和可追溯性，需要遵循一定的提交规范。
1. 提交前检查在提交待码前，应该进行以下检查：- 代码是否符合编码规范。
- 是否有未提交的代码变更。
SVN仓库目录结构规划
SVN仓库⽬录结构规划SVN仓库⽬录结构规划服务器2010-06-10 16:08:31 阅读109 评论0 字号：⼤中⼩订阅SVN仓库的负责⼈规划好仓库的⽬录结构。
推荐的⽬录结构如下图所⽰。
仓库的⼀级⽬录只有两个，分别为code和doc。
其中，doc主要⽤来放置先期的⽂档，code 主要⽤来放置⼯程的代码，也可以包含后期的⽂档。
仓库的⼆级⽬录只可以是branch与trunk两个⽬录，分别存放主⼲与分⽀。
trunk⽬录下直接存放⼯程⽂件。
branch⽬录下包括⼀些⼦⽬录分别对应各个分⽀。
图 2.4从SVN仓库中取出代码时，⼀定不要把整个仓库取出来，⽽应该只取出trunk⽬录，或只取出branch下的某个分⽀⽬录（⽐如上图中的svn:codebranchxw_051206）。
⼀个项⽬会有多个⼈共同合作开发完成。
基本流程是：●各开发成员建⽴⾃⼰的分⽀，并在此分⽀上开发；●各开发成员把分⽀合并到主⼲上并形成较为稳定的版本；●各个成员重新从主⼲上建⽴新的分⽀，在此分⽀上开发(即回到第⼀步)●循环往复，直到⼯程结束。
下⾯我⽤⼀个例⼦来说明合作开发的基本流程。
现在xb与lzj两个开发⼈员要共同开发⼀个⼯程onlytest，其这个⼯程的主⼲的SVN仓库地址如下图。
图 2.5xb与lzj分别在onlytest这个⼯程中建⽴两个分⽀，分别为xb _051115和lz_051115。
在这⾥分⽀命名要采⽤[姓名缩写_6个数的⽇期_后缀(可选)]的形式，⽐如xb_051208_1，xb_051212之类的。
创建完分⽀后我们可以看到这个⼯程的⽬录结构如下图所⽰：图 2.6分⽀⽬录建完之后，xb和lzj分别在本地取出对应的分⽀进⾏开发。
当程序到达⼀个⽐较稳定的阶段，就需要把分⽀合并到主⼲上，下⾯讲述⼀下合并的流程。
在本节中继续使⽤上⼀节中所⽰的⼯程与SVN仓库讲解。
1.2.3.1 xb与lzj分别修改⾃⼰分⽀上的代码现在，主⼲上的test_SVN.txt是空⽂档。
svn服务端目录结构说明
一：Svn server目录结构说明├─Product_A│├─branches│├─tags│└─trunk│├─doc├─ Requirement├─ Design├─ Code├─ Test├─ Implement├─ Release├─ ProjectManagement│├─Project├─ java├─ home├─ webapp├─ notice(修改记录等)│├─DB├─ DB2/Oracle├─ initdata├─ function├─ procedure├─ create(建库，工作空间，表，视图等脚本)├─ DPC├─ HDS│├─SDK(软件开发工具包,如dorado插件等)每个软件产品对应SVN根目录下的一个二级子目录。
每一个软件产品目录又主要包括如下三个部分：（1）Tag；（2）Trunk；（3）BranchesTag：按版本保存该软件产品所有的经过完整测试的历史稳定版本，相当于该软件产品的“里程牌”。
Trunk：目录是软件产品当前的主干开发版本。
Branches：目录是软件产品的迭代开发版本。
Branches目录中应按当前迭代的版本组织目录，版本目录下的子目录组织参考Trunk目录。
分为Tag，Trunk，Branches三个目录的主要原因是在项目分多期的情况下，一期上线后形成的稳定版本应该copy在Tag下并打上相应的标签如tag_release_1_0。
那么在二期启动后又发现的一期的BUG，这是二期处于开发阶段那么在trunk下直接修改bug发布到生成环境下是不现实的。
这时应该基于tag_release_1_0上做一个branch如branch_bugfix_1_0。
在branch_bugfix_1_0上修复BUG，并形成一个稳定版本并标记这个分支到Tag目录下为tag_release_1_1。
在将tag_release_1_1发布到生产环境中。
并根据需要将branch_bugfix_1_0合并到Trunk中。
源代码管理工具（下）-SVN目录结构
源代码管理⼯具（下）-SVN⽬录结构
正规项⽬的SVN⽬录结构⼀般有3个⽂件夹：
trunk：主⼲，当前开发项⽬的主⽬录
branches：分⽀⽬录，添加⾮主线功能时使⽤，开发测试之后，可以合并到主⼲项⽬中
tags：标记⽬录，通常作为重⼤版本的备份
在svn服务器上再次创建⼀个仓库，这个仓库死真正的仓库，包含了trunk、branches、tags三个⽂件夹，模拟开发、修复bug、合并版本的流程。
1.创建仓库
2.命名仓库
3.初始化仓库：
4.访问设置：
5.仓库创建成功，预览URL：
6.查看创建的三个⽂件夹：
7.接下来，根据项⽬的实际情况往trunk⽂件夹中添加⼦⽂件夹（例如code、doc等）
8.然后设置可以访问该仓库的⽤户（注意分配合适的访问权限read only、read/write）：
9.⾄此，SVN服务器上的仓库搭建斌配置完成，接下来⽤cornerstone连接仓库
10.连接成功：
11.选中远程仓库的trunk⽂件夹，点击Check Out，下载trunk⽂件夹下的所有内容（因为不需要check Out其他两个⽂件夹）
此时，本地相应⽂件夹下就已经有了svn服务器weibo项⽬仓库的trunk⽂件夹下的所有内容
12.接下来，Xcode新建项⽬，把项⽬存放到受svn管理的路径下
<img src="data:image/png;base64,iVBORw0K。
svn项目的目录规划布局
Subversion有一个很标准的目录结构，比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是svn://proj/|+-trunk+-branches+-tags这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。
但是具体这几个目录应该如何使用，svn并没有明确的规范。
对于这几个开发目录，一般的使用方法有两种。
我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。
第一种方法，使用trunk作为主要的开发目录。
一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。
此时应该基于当前冻结的代码库，打tag。
当下一个版本/阶段的开发任务开始，继续在trunk进行开发。
此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。
应该基于发行版对应的tag，做相应的分支（branch）进行开发。
例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序1. 1.0开发完毕，代码冻结2.基于已经冻结的trunk，为release1.0打tag此时的目录结构为svn://proj/+trunk/ (freeze)+branches/+tags/+tag_release_1.0 (copy from trunk)3. 2.0开始开发，trunk此时为2.0的开发版4.发现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)5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发6.在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等7.根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。
SVN的标准目录结构
SVN的标准⽬录结构
SVN⽬录规范
在visualSVN中创建仓库时,可以选择svn⽬录结构
Trunk主⼲⽬录,此⽬录下的⽂件为基准⽂件.
Brancher ⽤于开发的分⽀⽬录
Tags⽤于发布的版本⽬录
假设有⼀个项⽬OA,我们完成了1.0版本,这时就可以打⼀个tags
后续我们在OA项⽬上添加⼀个新的模块(及时通讯),我们就可以开⼀个分⽀,⼜有⼀个公司需要在我们OA基础上添加财务管理模块,我们⼜可以打⼀个分⽀.
我们后续针对OA的1.0版本在升级,我们不需要原来附加功能,就可以在原来的主⼲上继续开发,形成OA2.0版本,开发完成后就可以在打⼀个tags
分⽀与标记
打⼀个分⽀或者标记
分⽀的定义规则: Project name+⽇期时间+功能点 Tags的定义规则 Project name+版本号版本号定义为三段数字编号 xxx.xxx.xxx 第⼀个:⾰命性的产品升级版第⼆个:新功能版第三个:修正bug
切换主⼲，分⽀与标记
Tags⼀般是只读，它代表的是发布的版本，所以我们不要进⾏改变。
主⼲与分⽀的合并
如果要将主⼲内容合并到分⽀上，我们需要在分⽀的⼯作副本上操作。
如果要将分⽀的改变合并到主⼲上，我们需要在主⼲的⼯作副本上操作。
我们的需要是将分⽀的改变合并到主⼲上：
注意:在合并时要选择在相应的版本号，合并后，可能会出现冲突，将冲突解决，commit就可以。
svn版本库目录结构
svn版本库⽬录结构该⽂是svn源代码分析系列⽂章服务端架构中的⼀篇，主要描述svn服务端版本库数据存储⽬录结构，并且对这些⽂件以及⽬录的作⽤进⾏简单分析。
使⽤“svnmadin create”命令创建初始化版本库后，使⽤“tree”命令打印出没有经过任何修改的原始版本库⽬录。
$ svnadmin /svnrepos/morepos$ tree /svnrepos/morepos -pmorepos|-- [-rw-r--r--] README.txt|-- [drwxr-xr-x] conf| |-- [-rw-r--r--] authz| |-- [-rw-r--r--] passwd| `-- [-rw-r--r--] svnserve.conf|-- [drwxr-sr-x] db| |-- [-rw-r--r--] current| |-- [-r--r--r--] format| |-- [-rw-r--r--] fs-type| |-- [-rw-r--r--] fsfs.conf| |-- [-rw-r--r--] min-unpacked-rev| |-- [drwxr-sr-x] revprops| | `-- [drwxr-sr-x] 0| | `-- [-r--r--r--] 0| |-- [drwxr-sr-x] revs| | `-- [drwxr-sr-x] 0| | `-- [-r--r--r--] 0| |-- [drwxr-sr-x] transactions| |-- [-rw-r--r--] txn-current| |-- [-rw-r--r--] txn-current-lock| |-- [drwxr-sr-x] txn-protorevs| |-- [-rw-r--r--] uuid| `-- [-rw-r--r--] write-lock|-- [-r--r--r--] format|-- [drwxr-xr-x] hooks| |-- [-rw-r--r--] post-commit.tmpl| |-- [-rw-r--r--] post-lock.tmpl| |-- [-rw-r--r--] post-revprop-change.tmpl| |-- [-rw-r--r--] post-unlock.tmpl| |-- [-rw-r--r--] pre-commit.tmpl| |-- [-rw-r--r--] pre-lock.tmpl| |-- [-rw-r--r--] pre-revprop-change.tmpl| |-- [-rw-r--r--] pre-unlock.tmpl| `-- [-rw-r--r--] start-commit.tmpl`-- [drwxr-xr-x] locks|-- [-rw-r--r--] db-logs.lock`-- [-rw-r--r--] db.lock10 directories, 27 files路径类型作⽤conf⽬录存放版本库所⽤配置⽂件的⽬录dav⽬录供mod_dav_svn使⽤db⽬录版本数据存储⽬录db/fs-type⽂件版本库数据真实存储格式，SVN有fsfs和bdb两种存储格式db/revprops⽬录记录版本属性db/revs⽬录版本库数据存储真实⽬录db/uuid⽂件存储版本库唯⼀标识号，参考db/txn-current⽂件记录当前事务format⽂件存储⼀个整数的⽂件，此整数代表库层次结构版本hooks⽬录存放版本库勾⼦⽬录locks⽬录存储库锁⽬录，⽤来跟踪库的访问者其中revs下⾯是以⽬录组织的版本结构，每1000个版本组成⼀个⽬录，每个版本⾃成⼀个⽂件，⽂件名即为commit后⽣成的版本号；即使删除掉部分版本也不会影响版本库的读取和显⽰；但是基础版本丢失会使版本库⽆法访问；。
svn的存储目录结构
svn的 存 储 目 录 结 构
svn的存储目录结构一般建议在根目录下建立trunk、branches、tags这三个文件夹。 trunk用于平时的正常工作，一般与外网保持一致； branches用于存放各种分支，研发的用于存放开发分支； tags用于存放各种发布版本或某状态的快照； tags本质上和branches是一样的，都是一种分支，只是习惯上branches下面的东西会被修改、合并，而tags下面的东西则作为某阶段的状态保存不动； 一般tags下面经常放的都是各个发布版本，如Release0.91、Release1.23等。
SVN目录结构图说明
SVN目录，文档存放位置详细说明01-Workspace -----------------------工作区01- M anagedoc ----------------------管理文档01- PM --------------------项目研发管理01-Plan---------------------------------------------------项目策划表、项目主计划、项目主计划评审报告02-ChangeManage-------------------------------------项目变更单03-Milestone--------------------------------------------项目管理表、S模型迭代报告04-Meeting&Weekports-------------------------------会议和周报01- Meetings --------------------------会议纪要02- WeekReports -----------------------项目周报05-PMTrace---------------------------------------------其它文档02- QM ----------------------项目质量管控01- QAplan--------------------------------------------质量保证计划02- STplan--------------------------------------------系统测试计划03- ST01- TestDesign -------------------------系统测试用例、性能测试需求评审报告、易用性评审报告02- TestDevelop ----------------------系统测试报告04-preReviewReportsSRS ----------------------------------------软件软件需求预审报告TestCase -----------------------------------系统测试用例预审报告03- CM ---------------------配置管理01- CMaudit------------------------------------------配置库权限表、配置库备份记录表、配置项状态表02- CSAreport----------------------------------------配置管理周报03- ChangeManage--------------------------------项目变更一览表02- E ngineeringdoc -----------------工程文档01- RM -----------------------需求01-UserRM---------------------------------------------用户需求与立项表02-ProdRM---------------------------------------------可行性分析、总体方案、产品规划书、产品需求说明书、原型demo03-SRS-------------------------------------------------软件设计说明书、软件设计说明书评审与验证报告、product backlog、user story 02- Design -----------------------设计01- ArchDesign---------------------------------------架构设计说明书、架构设计说明书评审与验证报告02- SysDesign----------------------------------------系统设计说明书、系统设计说明书评审与验证报告03- DBdesign-----------------------------------------数据库设计说明书、数据库设计说明书评审与验证报告03- BasTest&CodeReview ----------单元测试和代码评审01- BasTestReports---------------------------------单元测试02-CodeReviewReports------------------------------代码评审报告04- Deploy -----------------------项目实施01- Plans&Reports----------------------------------实施计划、实施报告02- Deploydocs--------------------------------------其它实施文档03- Mamuals-----------------------------------------实施手册（安装手册、使用手册）03- S ource --------------------------源码01- EnvironmentAbout ---------------开发环境02- SourceCode -------------------源代码02-Baseline -------------------------基线区01- PlanLines -----------------------计划基线02- RequireLines -------------------需求基线03- DesignLines --------------------设计基线04- CodeReview -------------------代码评审工作区03-Test ------------------------------测试区04-Release -------------------------发布区01- Version --------------------------版本01-Relationdocs ----------------------发布单、发布清单02-ReleasePackages ---------------发布包02- ResultsItems -------------------项目总结报告、结项报告03- Outside --------------------------外发包05-TestPrepare -------------------提交测试包、外发包、提交测试标签记载06-WorkTags ----------------------代码标签区。
svn标准
SVN（Subversion）是一种版本控制系统，它提供了一套标准的命令和功能，用于管理和追踪软件开发项目中的代码版本变化。
它使用集中式的代码仓库来存储项目的代码和版本历史记录。
SVN标准目录结构：
* Trunk（主分支）：表示日常开发中的项目，任何时候Trunk里包含的都是最新的开发代码。
Trunk应该只被用来开发将会成为你的下一个重要版本的代码。
* Branches（分支）：可以用于处理trunk或release branches里发现的严重的Bug。
比如项目要升级2.0版本，但是发现1.0有bug，这时候，就可以将1.0的项目拷贝到该目录进行bug修复，在主分支进行版本升级。
之后进行合并。
* Tags（标签）：一般情况下，tag是用来做一个里程碑的，每次有重大版本更新，都会将项目拷贝到Tags中，做一个里程碑。
以上就是SVN标准的一些基本信息，如需了解更多内容，建议咨询专业技术人员。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
源代码，代码走查报告。 项目测试相关文档，如：测试计划，测试用例，测试总结报 告，等 存放项目上线实施后的相关文档，如：上线方案，实施总 结，操作手册，验收文档，维护手册，安装部署手册等
项目采购相关文档。
依次后推。子项目的目录结构同项目的目录结构。
操作手册 验收文档 维护手册 安装部署手册 06采购
说明：如项目包含多个子项目，可在一级目录后增加子项目，其他目录结构层级依次后推。子项目的目录结构 注意：请为PMO开通项目SVN目录只读权限。
目录结构
目录说明 项目立项时相关资料，如项目需求书，工作说明书，立项签 报等。
项目启动相关资料 项目执行与跟踪的活动文档，如：项目周报，风险及问题记 录，项目状态报告等 项目相关报告，如项目状ቤተ መጻሕፍቲ ባይዱ报告等 项目重要会议纪要 项目里程碑计划，进度计划
XXXX 项目SVN目录结构
项目配置接口人： 一级目录 二级目录 管理 01立项 产品资料 立项申请 项目需求 选型报告 总体计划 02启动 03监控 报告 会议纪要 项目计划 项目月计划 项目周计划 里程碑计划 周报 04结项 05培训 06质量 07资料 实施 01需求 业务需求类文档 需求设计分析类文档 需求跟踪 02设计 总体设计 概要设计 详细设计 数据结构设计 集成设计 03开发 04测试 源代码 走查报告 测试计划 测试用例 测试总结报告 05上线验收 上线方案 实施总结 评审报告 项目规范 厂商联系方式 厂商往来交流记录 项目周报 个人周报 三级目录 四级目录 五级目录
项目周报，个人任务跟踪表 项目结项相关资料 项目培训相关资料，如培训课件，培训签到表，培训考核反 馈表等 项目各阶段评审报告，检查单等 项目其他相关资料
项目的需求管理阶段活动文档，如：业务需求类文档，需求 设计分析类文档，需求跟踪类文档等
项目设计开放方面的文档，如：总体设计，概要设计，详细 设计，数据结构设计，集成设计等。