SVN的标准目录结构:trunk、branches、tags

标签: svn 标准 目录 | 发表时间:2012-07-03 23:46 | 作者:Tender001
出处:http://blog.csdn.net
我们在一些著名开源项目的版本库中,通常可以看到trunk, branches, tags等三个目录。由于SVN固有的特点,目录在SVN中并没有特别的意义,但是这三个目录却在大多数开源项目中存在,这是因为这三个目录反映了软件开发的通常模式。

trunk是主分支,是日常开发进行的地方。

branches是分支。一些阶段性的release版本,这些版本是可以继续进行开发和维护的,则放在branches目录中。又比如为不同用户客制化的版本,也可以放在分支中进行开发。

tags目录一般是只读的,这里存储阶段性的发布版本,只是作为一个里程碑的版本进行存档。

比如一个项目有main.cpp, common.h两个文件,假设目前在开发的是最新的3.0版本,而且1.0/2.0版本也在进行维护,那么项目树将类似如下样子:

project
  |
  +-- trunk
  +     |
  +     +----- main.cpp  (3.0版本的最新文件)
  +     +----- common.h
  +
  +-- branches
  +     |
  +     +-- r1.0
  +     +     |
  +     +     +---- main.cpp (1.x版本的最新文件)
  +     +     +---- common.h 
  +     +
  +     +-- r2.0
  +           |
  +           +---- main.cpp (2.x版本的最新文件)
  +           +---- common.h
  +      
  +-- tags   (此目录只读)
        |
        +-- r1.0
        +     |
        +     +---- main.cpp (1.0版本的发布文件)
        +     +---- common.h 
        +
        +-- r1.1
        +     |
        +     +---- main.cpp (1.1版本的发布文件)
        +     +---- common.h
        +
        +-- r1.2
        +     |
        +     +---- main.cpp (1.2版本的发布文件)
        +     +---- common.h 
        +
        +-- r1.3
        +     |
        +     +---- main.cpp (1.3版本的发布文件)
        +     +---- common.h
        +
        +-- r2.0
        +     |
        +     +---- main.cpp (2.0版本的发布文件)
        +     +---- common.h 
        +
        +-- r2.1
              |
              +---- main.cpp (2.1版本的发布文件)
              +---- common.h


要使用这样的文件夹结构,在建立项目版本库时,可首先建好项目文件夹,并在其中建立trunk, branches, tags三个空的子目录,再将项目文件夹连同这三个子目录一起导入版本库。

这样在trunk中开始进行开发,当需要建立branch或tag时,使用SVN的copy操作进行。

其中tags目录需要只读,可以使用SVN中的authz文件控制该目录的访问权限为只读。
作者:Tender001 发表于2012-7-3 23:46:22 原文链接
阅读:3 评论:1 查看评论

相关 [svn 标准 目录] 推荐:

SVN的标准目录结构:trunk、branches、tags

- - CSDN博客推荐文章
我们在一些著名开源项目的版本库中,通常可以看到trunk, branches, tags等三个目录. 由于SVN固有的特点,目录在SVN中并没有特别的意义,但是这三个目录却在大多数开源项目中存在,这是因为这三个目录反映了软件开发的通常模式. trunk是主分支,是日常开发进行的地方. 一些阶段性的release版本,这些版本是可以继续进行开发和维护的,则放在branches目录中.

svn 钩子开启

- - 运维技术的个人空间
背景: 公司的Svn很多人在用,有不少人在作修改后不添加注释,所以需要强制用户填写注释. 重命名svn主目录中hooks的pre-commit.tmpl文件为pre-commit,并添加可执行权限. echo "【注释】$content" 1>&2. echo "【注意】注释不能为空,请重新填写注释!!!" 1>&2.

SVN强制填写日志

- - CSDN博客系统运维推荐文章
在F:\Repositories\版本库名\hooks下新建pre-commit.bat. rem 保证输入8个字符 %SVN_BINDIR%\svnlook log %REPOS% -t %TXN% | findstr "........" > nul if %errorlevel% gtr 0 goto :err_action rem 过滤空格字符 %SVN_BINDIR%\svnlook log %REPOS% -t %TXN% | findstr /ic:".

SVN之使用原则

- - 研发管理 - ITeye博客
以下是我起草的部门SVN规范里原则的一部分. 必须提交注释,注明相关修改信息,例如bug号、任务描述等. 具体内容可采用约定或者设置的形式. 你所提交的改变将体现给其他开发者,要明白提交的后果,. 代码变动及时提交,避免丢失本地修改后无法恢复. 新增加的文件同时被提交,否则只在你本地能正常工作,导致其它人不能编译通过.

使用VisualSVN Server搭建SVN服务器

- - CSDN博客推荐文章
使用 VisualSVN Server来实现主要的 SVN功能则要比使用原始的 SVN和 Apache相配合来实现源代码的 SVN管理简单的多,上手也没有那么复杂. VisualSVN Server的下载地址如下,是免费的,随意不必有顾虑. 1使用SVN,首先要安装 TortoiseSVN,就是上面的SVN下载地址.

SVN:合并一个分支到主干

- - P.Linux Laboratory
本文内容遵从 CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/program/svn_merge_branch_trunk.html. 原文在此,我只是翻译: http://www.sepcot.com/blog/2007/04/SVN-Merge-Branch-Trunk.

[原]强制 code review:reviewboard+svn 的方案

- - 赖勇浩的编程私伙局
赖勇浩( http://laiyonghao.com). 我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.

SVN提交更新的一个准则

- - BlogJava_首页
查阅了一下网络和博客园,发现还没有一个明确地指导源码管理提交准则的相关文章,因此斗胆整理了一部分自己平时开发管理的心得,加上查阅了部分英文资料写了一个不算很完善的SVN提交准则. 负责而谨慎地提交自己的代码. SVN更新的原则是要随时更新,随时提交. 当完成了一个小功能,能够通过编译并且并且自己测试之后,谨慎地提交.

SVN:分支合并到主干

- - CSDN博客系统运维推荐文章
1.先把主干代码下载到本地. 3.svn merge 分支目录    . 4.遇到冲突, 请见合并日志,选择"p",记下出冲突的文件,人工编辑.  4.1 比如Index.action出冲突了,vi Index.action.  4.2 vi完成以后,删除冲突的文件 rm -f Index.action.*.

svn提交时强制注释

- -
不少开发员提交修改的时候都不写注释,导致查看历史时很费劲,也不太符合规范. 有的公司要求每次提交修改时都写上bug号或者任务描述,那么如何在工具上防止开发员们不写注释呢.   利用svn的pre-commit钩子可简单实现此要求. 进入仓库project1/hooks目录,找到pre-commit.tmpl文件,重命名,去掉后缀.tmpl.