对subversion中trunk的认识

xblues

在将数据导入到仓库之前，你必须先想好如何组织存放你的数据。如果你使用一种我们推荐的规划方式，你将在以后的使用中感觉到很舒服。

我们这里有很多种标准的推荐仓库组织形式。大多数人会创建一个trunk目录来存放开发的“主线”，一个branches目录来存放支线副本，另外还有一个tags目录来存放标签副本。假如一个仓库只保存一个项目，经常会创建这样的几个顶级目录：

/trunk

/branches

/tags

如果一个仓库存放多个项目，经常会像下面这样根据分支来规划：

/trunk/paint

/trunk/calc

/branches/paint

/branches/calc

/tags/paint

/tags/calc

...或者根据项目分成多个目录：

/paint/trunk

/paint/branches

/paint/tags

/calc/trunk

/calc/branches

/calc/tags

如果多个项目之间的关系不是很紧密，并且他们都是被单独取出的，那根据项目来规划会比较有意义些。For related projects where you may want to check out all projects in one go, or where the projects are all tied together in a single distribution package, it is often better to index by branch. This way you have only one trunk to checkout, and the relationships between the sub-projects is more easily visible.对那些相关的项目（），最好根据分支来组织规划。这样的话，你就只有一个trunk需要checkout，而且子项目间的关系会更明显。

你如果采用/trunk /tags /branches并列于根目录的方式，那你必须为每个branch和tag复制整个trunk，也就是说这种结构显得更机动些。

对不相干的项目来说，你可以使用多个不同的仓库。当你提交一个改动，版本号会是整个仓库的版本号，而不是项目的版本号。2个不相干的项目共享一个仓库会在版本号方面导致极大的不方便。Subversion和TortoiseSVN的项目看起来好像在同一个地址，但事实上他们在完全不同的仓库中研发着，并且在版本号方面完全的不相干。

当然，你可以不管上面提到的这些形式。你可以随意发挥以满足你或者你的团队的需要。记住不管你怎么选择，那都不会是一个永久的形式，你可以在任何时候重新组织你的仓库。因为branches和tags都是很普通的目录，只要你愿意，TortoiseSVN可以随时移动它们，或改名。

从一种形式转换到另一种形式仅仅需要在服务器端做一些文件或目录移动操作；如果你不喜欢你仓库的某种组织形式，尽管大胆的操作那些目录。

到这里，如果你还没有在你的仓库中创建一个基本的目录架构，接下来你应该这么做：

1.        在你的硬盘中创建一个空目录。

2.        在这个目录中创建一个你中意的目录组织形式。注意现在不要放任何文件进去。

3.        接下来把这个结构导入仓库。在新建的那个目录上单击鼠标右键，选择Import…。这样，就把你刚才创建的临时目录导入到仓库的根目录了，并创建了仓库的基本架构。

注意：你导入的这个目录的目录名是不应该出现在仓库中的，应该只有目录中的内容会出现。比如，创建下面的目录结构：

C:TempNewtrunk

C:TempNewbranches

C:TempNewtags

将C:TempNew 导入到仓库的根目录，那么根目录看起来应该是这样的：

/trunk

/branches

/tags

另外你也可以使用仓库浏览器（repository browser）直接在仓库中创建新目录。

xblues

你一定注意到了Subversion极度的灵活性，因为它用相同的底层机制（目录拷贝）实现了分支和标签，因为分支和标签是作为普通的文件系统出现，会让人们感到害怕，因为它太灵活了，在这个小节里，我们会提供安排和管理数据的一些建议。
                                                                                                                                                                                                                                                        版本库布局                                                               
                                                
                                
有一些标准的，推荐的组织版本库的方式，许多人创建一个trunk目录来保存开发的“主线”，一个branches目录存放分支拷贝，一个目录保存标签拷贝，如果一个版本库只是存放一个项目，人们会在顶级目录创建这些目录：
/trunk
/branches
/tags
如果一个版本库保存了多个项目，管理员会通过项目来布局（见“选择一种版本库布局”一节关于“项目根目录”）：
/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags
当然，你可以自由的忽略这些通常的布局方式，你可以创建任意的变化，只要是对你和你的项目有益，记住无论你选择什么，这不会是一种永久的承诺，你可以随时重新组织你的版本库。因为分支和标签都是普通的目录，svn move命令可以任意的改名和移动它们，从一种布局到另一种大概只是一系列服务器端的移动，如果你不喜欢版本库的组织方式，你可以任意修改目录结构。
记住，尽管移动目录非常容易，你必须体谅你的用户，你的修改会让你的用户感到迷惑，如果一个用户的拥有一个版本库目录的工作拷贝，你的svn move命令也许会删除最新的版本的这个路径，当用户运行svn update，会被告知这个工作拷贝引用的路径已经不再存在，用户需要强制使用svn switch转到新的位置。
               
数据的生命周期                                                               
另一个Subversion模型的可爱特性是分支和标签可以有有限的生命周期，就像其它的版本化的项目，举个例子，假定你最终完成了calc项目你的个人分支上的所有工作，在合并了你的所有修改到/calc/trunk后，没有必要继续保留你的私有分支目录：
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch
             -m "Removing obsolete branch of calc project."

Committed revision 375.
你的分支已经消失了，当然不是真的消失了：这个目录只是在HEAD修订版本里消失了，如果你使用svn checkout、svn switch或者svn list来检查一个旧的版本，你仍会见到这个旧的分支。
如果浏览你删除的目录还不足够，你可以把它找回来，恢复数据对Subversion来说很简单，如果你希望恢复一个已经删除的目录（或文件）到HEAD，仅需要使用svn copy -r来从旧的版本拷贝出来：
$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch
http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.
在我们的例子里，你的个人分支只有一个相对短的生命周期：你会为修复一个Bug或实现一个小的特性来创建它，当任务完成，分支也该结束了。在软件开发过程中，有两个“主要的”分支一直存在很长的时间也是很常见的情况，举个例子，假定我们是发布一个稳定的calc项目的时候了，但我们仍会需要几个月的时间来修复Bug，你不希望添加新的特性，但你不希望告诉开发者停止开发，所以作为替代，你为软件创建了一个“分支”，这个分支更改不会很多：
$ svn copy http://svn.example.com/repos/calc/trunk
         http://svn.example.com/repos/calc/branches/stable-1.0
         -m "Creating stable branch of calc project."

Committed revision 377.
而且开发者可以自由的继续添加新的（试验的）特性到/calc/trunk，你可以宣布这样一种政策，只有bug修正提交到/calc/branches /stable-1.0，这样的话，人们继续在主干上工作，某个人会选择在稳定分支上做出一些Bug修正，甚至在稳定版本发布之后。你或许会在这个维护分支上工作很长时间—也就是说，你会一直继续为客户提供这个版本的支持。

作者:korezu Inc
转载自:http://www.cnitblog.com/tilan/articles/21816.html

xblues

在SVN中Branch/tag在一个功能选项中，在使用中也往往产生混淆。

在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs）。

一般情况下，
tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。

比如，3.0开发完成，这个时候要做一个tag，tag_release_3_0，然后基于这个tag做release，比如安装程序等。trunk进入 3.1的开发，但是3.0发现了bug，那么就需要基于tag_release_3_0做一个branch，branch_bugfix_3_0，基于这个branch进行bugfix，等到bugfix结束，做一个tag，tag_release_3_0_1，然后，根据需要决定 branch_bugfix_3_0是否并入trunk。

对于svn还要注意的一点，就是它是全局版本号，其实这个就是一个tag的标记，所以我们经常可以看到，什么什么release，基于xxx项目的2xxxx版本。就是这个意思了。但是，它还明确的给出一个tag的概念，就是因为这个更加的可读，毕竟记住tag_release_1_0要比记住一个很大的版本号容易的多。

black_zerg

i think everything in svn is just a folder so never care if it's branch or tag

xblues

大家遵循共同的命名结构还是有必要的。