`

SVN索引

阅读更多

最近在进行项目的版本目录管理,借鉴了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(什么时候进行这步操作,要根据具体情况) 
    这是一种很标准的开发模 式,很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

    第二种方法,在每一个release的branch中进行 各自的开发,trunk只做发布使用。这种开发模式当中,trunk是不承担具体开发任务的,一个版本/阶段的开发任务在开始的时候,根据已经 release的版本做新的开发分支,并且基于这个分支进行开发。还是举上面的例子,这里面的时序关系是。

1.1.0开发,做 dev1.0的branch
此时的目录结构
svn://proj/
+trunk/ (不担负开发任务 )
+branches/
    +dev_1.0 (copy from trunk)
+tags/ 
2.1.0开发完成,merge dev1.0到trunk
此时的目 录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
     +dev_1.0 (开发任务结束,freeze)
+tags/ 
3.根据trunk做1.0的tag
此时的目录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
    +dev_1.0 (开发任务结束,freeze)
+tags/
    +tag_release_1.0 (copy from trunk) 
4.1.0开发,做dev2.0分支
此时的目录结构
svn://proj/
+trunk/ 
+branches/
    +dev_1.0 (开发任务结束,freeze)
    +dev_2.0 (进行2.0开发)
+tags/
    +tag_release_1.0 (copy from trunk) 
5.1.0有bug,直接在dev1.0的分支上修复
此时的目录结构
svn://proj/
+trunk/ 
+branches/
    +dev_1.0 (1.0bugfix)
    +dev_2.0 (进行2.0开发)
+tags/
    +tag_release_1.0 (copy from trunk) 
6.选择性的进行代码merge 
    这其实是一种分散式的开发,当各个部分相对 独立一些(功能性的),可以开多个dev的分支进行开发,这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache 等。但是这样merge起来就是一个很痛苦的事情。

    这里要注意一下的,第六步进行选择性的merge,是可以当2.0开发结束后一起把 dev_1.0(bugfix用)和dev_2.0(新版本开发 用)merge回trunk。或者先把dev_1.0 merge到dev_2.0,进行测试等之后再merge回trunk。
     这两种方法各有利弊,第一种方法是可以得到一个比较纯的dev_2.0的 开发分支,而第二种方法则更加的保险,因为要测试嘛。

      以上呢,就是我说的两种开发模式了,具体哪种好,并没有定论。这里大致的说一下各自 的优缺点
      第一种开发模式(trunk进行主要开发,集中式):
          优点:管理简单
          缺点:当开发的模块比较多,开发人数/小团队比较多 的时候,很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
      第二重开发模式(分支进行主要开发,分散式):
          优点:各 自开发独立,不容易相互影响。
          缺点:管理复杂,merge的时候很麻烦,容易死人。

      其实,这里并没有一定之规,更多的时候是两种 模式结合使用。

 

 

 

本节向大家讲解一下SVN目录结构组成,之前几节我们学习了SVN库的目录结构相信大家应该掌握了,在这里和大家简单介绍一下SVN目录结构组成,欢迎大家一起来学习。

首先看一下下面的这个结构。

wolfwebadmin
├─ProjectManagement
│├─trunk
│├─branches
│└─tags
└─SSO
├─trunk
├─branches
└─tags
大概的说一下,ProjectManagement和SSO是两个项目trunk是开发的主线代码,存放能够运行的正确的代码;程序员如果开发新的程序或者改bug,一般要先branch(SVN的一个功能)trunk目录下的代码到branches目录的一个子目录,在那里对代码进行修改,确认无误后再提交到trunk主线下(但是有的时候为了效率,我们也多人都在trunk目录下开发项目).tags目录可以看做主线代码的快照,比如你做了1.0又做了2.0,那每个不同版本的代码你就做快照放到tags文件夹下了。


一个Subversion版本库实现了一种版本化的文件系统,版本库只是一个包含目录和文件的文件系统,而且它的文件系统是版本化的,并且实现了”廉价”拷贝,让它的这种操作比传统文件系统便宜很多,但是版本库本身还是像一个文件系统:Subversion本身没有特别的目录或名称用来代表trunk或branches,他们只是文件系统的普通目录,这依赖于你给这些目录名和结构的一种意义。也就是说,社区已经采纳了多种普通的布局作为最佳实践,因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的,根据这些习惯,用户可以方便的访问版本库来查找他们所需要的。
有两种常见的SVN目录结构布局:
trunk
branches
tags
第一种布局是版本库包含一个项目或一组紧密联系项目的最佳选择,这个布局非常好用,因为分支与标签整个项目或一组项目会非常简单,只需要一个简单的命令:
svncopyurl://repos/trunkurl://repos/tags/tagname-m“Createtagname”
这可能是最常用的版本库布局,被许多开源项目采用,就像Subversion本身和Subclipse,这是大多数主机站点,如Tigris.org,SourceForge.net和GoogleCode遵循的方法,这些站点的每个项目有自己的版本库。
另一种SVN目录结构布局是针对一个版本库包含不相关项目的最佳选择。
ProjectA
trunk
branches
tags
ProjectB
trunk
branches
tags
在这种布局里,每个项目会存在顶级目录里,然后该目录之下创建trunk/branches/tags,其中与第一种布局相同,这只是将项目放到自己版本库方式的替换,他们都在一个版本库中。Apache软件基金会使用这种布局方式来存放他们的所有项目在一个版本库。
通过这种布局,每个项目都有自己的分支和标签,可以很容易使用一个命令创建分支和标签,就像前面展示的:
svncopyurl://repos/ProjectA/trunkurl://repos/ProjectA/tags/tagname-m“Createtagname”
这种布局可以简单的创建同时包含ProjectA和ProjectB的标签,你可以这样做,但是需要多个命令,你也要决定是否创建一个特别的目录存放这种分支和标签,如果你需要经常这样做,你或许应该考虑第一种SVN目录结构布局。


至于版本库中目录的名称,再说一遍:只是一种习惯,他们在Subversion中没有特别含义。
“trunk”可以认为是项目的开发主线,你可以称之为“main”,”mainline”,”production”或任何你喜欢的名字。
“branches”是放置分支的地方,人们因各种目的使用分支,你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等,在这个例子里,你可以在branches创建一层目录,或只是在顶级目录创建多个分支目录。


“tags”也不会被Subversion特别对待,他们只是习惯,或许通过钩子脚本或授权规则进行强制,来指明你创建了一个时间点的快照,通常情况下tags与分支的区别就是tags一旦创建不能修改,你也可以将标签目录叫做”releases”,”snapshots”,”baselines”或任何你喜欢的。
记住,名称对你有意义,不是Subversion。最后,Subversion的架构,全局修订版本经常使得标签没有必要,我不知道只是因为要创建tag而创建tag有什么意义,如果你需要在特定时间点重建软件,你可以通过svnlog来确定相关的修订版本号。tags对于版本库的”外部”用户很有用,或许QA/Release团队需要执行构建,或许是一个内部开发小组希望在另一个产品使用发布版本,或是外部用户或客户希望根据字面含义从版本库获取发布快照,在这些场景中,创建tag是保证获取正确代码的最简单方法,也需要有好的交流机制来指明发布快照。


希望本文可以为你澄清一些问题,让你更好的理解Subversion是如何工作的。最后,我希望指出Subversion版本库的布局是可以修改的,你可以一直重组和重构布局,最坏情况下,会让用户调整他们的工作拷贝,但不会让你从头再来,你应该自由的改名,移动目录或任何你希望改变版本库的方式去做。本节关于SVN目录结构讲解完毕,请关注本节其他相关报道。

 

 

 


本节和大家讨论一下SVN库的目录结构问题,这里我发表一下个人理解,和大家讨论讨论,欢迎大家一起来学习SVN库的目录结构方面的知识。
1、所有项目都在一个SVN库中么?
对于这个问题,个人认为,应该每个项目建一个SVN库,为什么这样说呢,因为SVN是全局版本,假如SVN库是如下结构:
SVN库<全局版本1.1>
┠项目A<1.1>
┖项目B<1.1>
这就会导致任何一个项目修改,影响全局版本修改,不能真实反映单个项目的版本情况。
2、SVN库的目录结构该怎样规划?
参考了国外一些主要的开发网站,如SourceForge,大同小异,类似这样的目录结构:
SVN库
┠tags(发布)
┃├1.1rc1
┃├1.2
┃├1.5
┃└1.9
┠trunk(主版本)
┃└project
┃├src
┃├classes
┃└WEB-INF
┖branches(分支)
└分支
主要的开发工作放在trunk,分支放在branches,发布版本放在tags。
存储库
┠项目名
┃├trunk:主版本
┃├branches:分支版本(独立版本)
┃└tags:标记版本,比如发行版v1.0/v2.0等等
3、SVN库的管理原则:
1、项目负责人和版本管理员负责架构项目目录结构,包括配置文件、第三方JAR文档
2、项目负责人分配开发人员目录权限,由版本管理员负责实施,权限分配粒度要细
3、trunk,tags,branches,项目负责人、协同版本管理员构建tags和branches
4、版本管理员负责解决开发人员在开发过程中的有关版本问题
5、开发人员每次修改,或者新增、删除、拷贝工作区对象后,应该立刻提交到版本库,有效保持工作区与资源库的高度一致,每天下班之前提交、(更新)
6、开发人员在每次修改工作区中代码或者文档时,首先更新该对象,可以尽量减少冲突、合并
7、保证提交到的版本库的代码没有BUG以免影响开发组,可以适当利用加锁机制,减少冲突
8、项目负责人和版本管理员负责软件的测试版,构建测试环境,branches由版本管理员进行(checkout)
9、项目负责人和版本管理员负责发布软件的发布版,与系统部协调构建发布环境(export)
10、版本管理员负责清理有关不需要的branches,tags。本节关于SVN库的目录结构讲解完毕。

分享到:
评论

相关推荐

    Web方式的SVN全文搜索功能实现

    6. **SVN索引库**:存储从SVN仓库中提取出来的文件内容的索引及文件副本。 ##### 实现过程 1. **创建索引**: - 使用Lucene根据SVN仓库中的最新版本来初始化索引库。 - 索引构建过程中,需要遍历SVN仓库中的所有...

    jira和svn的集成

    启动过程中,系统会在特定目录下创建用于保存SVN索引的文件夹。 6. 在浏览器中访问JIRA实例(如 ***),可以查看到JIRA系统中已经安装并启用的Subversion plugin的信息。 7. 在JIRA系统中的Issue详细信息界面,...

    SVN SEARCHER 配置安装手册

    4. **初始化索引**:运行 SVN SEARCHER 的索引器,对你的SVN库进行索引。这一步可能需要一段时间,具体命令行操作可能如下: ``` ...

    myeclise 的svn 插件

    7. **索引文件(index.html)**:这可能是包含插件介绍或操作指南的网页文件,用户可以通过阅读了解更详细的使用方法。 8. **content.jar、artifacts.jar**:这些通常是插件打包时生成的JAR文件,包含了插件的资源和...

    svn 同步图标消失,并且不能勾选svn

    5. **清理并重建索引**:在“首选项”中,进入“Team” -&gt; “SVN” -&gt; “资源”,勾选“自动清除索引”,然后手动执行“清除索引”操作,接着重新构建索引。 6. **检查工作副本状态**:确认你的项目工作副本没有...

    sqlite3-用于SVN下的数据指令操作

    在SVN(Subversion)版本控制系统中,SQLite3常被用作仓库元数据的存储库,这使得SVN可以对文件历史、版本控制和其他相关信息进行高效管理。 SQLite3的数据指令操作主要包括以下几类: 1. 数据库连接与断开: ...

    svn1.10jar包

    1. **index.html**:这通常是一个网页索引文件,可能是SVN相关文档的起始页,用于介绍或引导用户了解SVN 1.10的特性、安装和使用方法。 2. **content.jar**:这是包含SVN内容的Java归档文件,可能包含了类库、资源...

    Eclipse Svn Connectors

    3. `index.php`:这个文件可能是网站索引,可能用于在线文档或更新站点,帮助用户查找和获取最新版本的connectors。 4. `site.xml`:这是Eclipse插件更新站点的描述文件,列出了可用的插件和更新信息,Eclipse可以...

    eclipse svn connectors

    - `index.html`:可能是一个简单的网页索引,用于介绍或引导用户安装和使用Eclipse SVN Connectors。 - `content.jar`:通常包含Eclipse插件的元数据和内容描述。 - `artifacts.jar`:可能包含了插件的二进制文件...

    windows下apache+svn

    - `DirectoryIndex`:设置默认索引文件,如 `index.html`。 3. 为了允许 Apache 服务启动,需在 `httpd.conf` 中取消以下行的注释: ``` LoadModule php5_module "c:/php/php5apache2_2.dll" AddType ...

    SVN中文帮助文档CHM

    CHM文件是一种常见的帮助文档格式,由一系列HTML页面组成,可以通过内置的索引和搜索功能快速查找信息。《SVN中文帮助文档CHM》包含了TortoiseSVN的安装、配置、基本操作、高级特性、问题解决等全方位的指南。 在这...

    svn的插件下载

    5. **index.html**:可能是插件的帮助文档或在线文档的索引页面,它提供了关于如何使用插件的详细说明,包括各种操作步骤、常见问题解答和功能介绍。 6. **site.xml**:这个文件是Eclipse Update Site的描述文件,...

    svn说明 压缩包

    2. **index.html**:这是HTML文件,可能是SVN文档的索引或入门指南。它可能会提供关于如何安装、配置和使用SVN的基本信息,包括命令行工具的用法、GUI客户端的推荐以及常见问题解答。 3. **plugins**:这个目录可能...

    eclipse svn中文插件

    - `index.html`:可能是插件的介绍页面或帮助文档的索引。 - `content.jar`:包含插件的资源和内容,如图片、样式表等。 - `artifacts.jar`:可能包含了插件的元数据和构建信息。 - `site.xml`:Eclipse插件更新站点...

    Git-SVN面试题,都是来自工作中的笔记

    ### Git与SVN的核心区别 #### 版本控制模型的不同 - **SVN**:集中式版本控制系统。所有的数据(包括文件版本、日志、差异等)都存储在一个中心服务器上,用户通过客户端软件与该服务器进行交互。这种方式下,每一...

    svn最新版eclipse插件

    1. `index.html`:这是插件的索引页面,可能包含插件的介绍、帮助文档或者其他相关信息。 2. `content.jar`:这是一个JAR(Java Archive)文件,通常包含了插件的资源、配置文件等内容。 3. `artifacts.jar`:这个...

    Eclipse SVN 插件 离线安装包 3.0.5

    - index_.html、index.php: 可能是用于插件网站或帮助文档的索引文件。 - content.jar、artifacts.jar: 这些是Java的JAR文件,可能包含插件的资源和元数据。 - pack.properties: 描述了包的属性,如版本信息。 - ...

    eclipse 4.6 neno SVN插件包

    - `index_.html`:可能是插件的主页面或者帮助文档的索引。 - `content.jar`和`artifacts.jar`:包含插件的资源和元数据,用于Eclipse识别和运行插件。 - `index.php`:可能是一个网页文件,用于在线帮助或文档。...

    SVN 64位插件

    1. `p2.index`:这是一个Eclipse插件的索引文件,用于帮助Eclipse的更新管理器识别和安装插件。 2. `content.jar`和`artifacts.jar`:这些是归档文件,通常包含插件的元数据和实际代码。`content.jar`可能包含了...

    svn server 3.0企业版

    5. 性能优化:3.0 版本可能包含了性能提升的改进,比如更快的文件索引、更高效的网络传输和数据存储,以应对大规模项目和高并发的使用场景。 6. 数据备份与恢复:企业版通常会提供更强大的备份和恢复机制,确保即使...

Global site tag (gtag.js) - Google Analytics