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

一下文字转自http://rocksun.cn/svn/?p=43 Subversion版本库布局 很多人问我”什么是推荐的版本库布局？”，”trunk是什么意思？”或”trunk有什么意义？”，本文将会尝试回答这个问题。

一个Subversion版本库实现了一种版本化的文件系统，版本库只是一个包含目录和文件的文件系统，而且它的文件系统是版本化的，并且实现了” 廉价”拷贝，让它的这种操作比传统文件系统便宜很多，但是版本库本身还是像一个文件系统：Subversion本身没有特别的目录或名称用来代表 trunk或branches，他们只是文件系统的普通目录，这依赖于你给这些目录名和结构的一种意义。

也就是说，社区已经采纳了多种普通的布局作为最佳实践，因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的，根据这些习惯，用户可以方便的访问版本库来查找他们所需要的。

有两种常见的布局：

第一种布局是版本库包含一个项目或一组紧密联系项目的最佳选择，这个布局非常好用，因为分支与标签整个项目或一组项目会非常简单，只需要一个简单的命令：

svn copy url://repos/trunk url://repos/tags/tagname -m “Create tagname”

这可能是最常用的版本库布局，被许多开源项目采用，就像Subversion本身和Subclipse，这是大多数主机站点，如Tigris.org, SourceForge.net和Google Code遵循的方法，这些站点的每个项目有自己的版本库。

另一种布局是针对一个版本库包含不相关项目的最佳选择。

在这种布局里，每个项目会存在顶级目录里，然后该目录之下创建trunk/branches/tags，其中与第一种布局相同，这只是将项目放到自己版本库方式的替换，他们都在一个版本库中。Apache软件基金会使用这种布局方式来存放他们的所有项目在一个版本库。

通过这种布局，每个项目都有自己的分支和标签，可以很容易使用一个命令创建分支和标签，就像前面展示的：

svn copy url://repos/ProjectA/trunk url://repos/ProjectA/tags/tagname -m “Create tagname”

这种布局可以简单的创建同时包含ProjectA和ProjectB的标签，你可以这样做，但是需要多个命令，你也要决定是否创建一个特别的目录存放这种分支和标签，如果你需要经常这样做，你或许应该考虑第一种布局。

至于版本库中目录的名称，再说一遍：只是一种习惯，他们在Subversion中没有特别含义。

“trunk”可以认为是项目的开发主线，你可以称之为 “main”，”mainline”，”production”或任何你喜欢的名字。

“branches”是放置分支的地方，人们因各种目的使用分支，你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等，在这个例子里，你可以在branches创建一层目录，或只是在顶级目录创建多个分支目录。

“tags”也不会被Subversion特别对待，他们只是习惯，或许通过钩子脚本或授权规则进行强制，来指明你创建了一个时间点的快照，通常情况下tags与分支的区别就是tags一旦创建不能修改，你也可以将标签目录叫做”releases” ，”snapshots”，”baselines”或任何你喜欢的。

记住，名称对你有意义，不是Subversion。最后，Subversion的架构，全局修订版本经常使得标签没有必要，我不知道只是因为要创建 tag而创建tag有什么意义，如果你需要在特定时间点重建软件，你可以通过svn log来确定相关的修订版本号。tags对于版本库的”外部”用户很有用，或许QA/Release团队需要执行构建，或许是一个内部开发小组希望在另一个产品使用发布版本，或是外部用户或客户希望根据字面含义从版本库获取发布快照，在这些场景中，创建tag是保证获取正确代码的最简单方法，也需要有好的交流机制来指明发布快照。

希望本文可以为你澄清一些问题，让你更好的理解Subversion是如何工作的。

最后，我希望指出Subversion版本库的布局是可以修改的，你可以一直重组和重构布局，最坏情况下，会让用户调整他们的工作拷贝，但不会让你从头再来，你应该自由的改名，移动目录或任何你希望改变版本库的方式去做。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号