“分支”、“标签”是什么意思？ 和“行李箱” 在 Subversion 存储库中是什么意思？
我在 Subversion（我猜是通用存储库）讨论中经常看到这些词。
过去几年我一直在我的项目中使用SVN，但我从未掌握这些目录的完整概念。
他们的意思是什么？
I've seen these words a lot around Subversion (and I guess general repository) discussions.
I have been using SVN for my projects for the last few years, but I've never grasped the complete concept of these directories.
What do they mean?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
首先，正如 @AndrewFinnell 和 @KenLiu 指出的那样，在 SVN 中，目录名称本身没有任何意义——“主干、分支和标签”只是大多数存储库使用的常见约定。 并非所有项目都使用所有目录（根本不使用“标签”是相当常见的），事实上，没有什么可以阻止您随意称呼它们，尽管打破约定通常会令人困惑。
我将描述分支和标签最常见的使用场景，并给出如何使用它们的示例场景。
主干：主要开发区域。 这是代码的下一个主要版本所在的位置，并且通常具有所有最新功能。
分支：每次发布主要版本时，都会创建一个分支。 这使您可以修复错误并发布新版本，而无需发布最新的（可能是未完成或未经测试的）功能。
标签：每次发布版本（最终版本、候选版本 (RC) 和测试版）时，您都会为其创建一个标签。 这为您提供了代码在该状态下的时间点副本，允许您在必要时返回并重现过去版本中的任何错误，或者完全按原样重新发布过去的版本。 SVN 中的分支和标签是轻量级的 - 在服务器上，它不会制作文件的完整副本，只是一个标记，表示“这些文件是在此版本中复制的”，仅占用几个字节。 考虑到这一点，您永远不应该担心为任何已发布的代码创建标签。 正如我之前所说，标签经常被省略，而是在发布版本时通过变更日志或其他文档来阐明修订号。
例如，假设您开始一个新项目。 您开始在“主干”中工作，最终将发布 1.0 版。
1.0.0 完成后，您将 trunk 分支到一个新的“1.0”分支，并创建一个“1.0.0”标签。 现在，最终的 1.1 版本的工作仍在 trunk 中继续进行。
您在代码中遇到一些错误，并在主干中修复它们，然后将修复合并到 1.0 分支。 您也可以做相反的事情，修复 1.0 分支中的错误，然后将它们合并回主干，但通常项目坚持单向合并只是为了减少丢失某些内容的机会。 有时，一个错误只能在 1.0 中修复，因为它在 1.1 中已过时。 这并不重要：您只想确保发布的 1.1 版本中不会包含 1.0 版本中已修复的相同错误。
一旦你发现足够的错误（或者可能是一个严重的错误），您决定发布 1.0.1 版本。 因此，您从 1.0 分支创建一个标签“1.0.1”，并发布代码。 此时，主干将包含 1.1 代码，“1.0”分支包含 1.0.1 代码。 下次发布 1.0 的更新时，它将是 1.0.2。
最终您几乎准备好发布 1.1，但您想先进行测试版。 在这种情况下，您可能会创建“1.1”分支和“1.1beta1”标签。 现在，1.2（或者可能是 2.0）的工作将在主干中继续进行，但 1.1 的工作将在“1.1”分支中继续进行。
一旦发布 1.1 Final，您就可以从“1.1”分支创建“1.1”标签。
如果您愿意，您还可以继续维护 1.0，在所有三个分支（1.0、1.1 和 trunk）之间移植错误修复。 重要的一点是，对于您正在维护的软件的每个主要版本，您都有一个包含该版本的最新版本代码的分支。
分支的另一个用途是用于功能。 这是您分支主干（或您的发布分支之一）并独立开发新功能的地方。 功能完成后，您可以将其合并回来并删除分支。
这个想法是当你正在做一些颠覆性的事情时（即会阻碍或干扰其他人做他们的工作），一些实验性的东西（甚至可能不会成功），或者可能只是一些需要很长时间的东西（并且你担心如果它阻碍了 1.2 版本的发布，当你准备好从主干分支 1.2），您可以在分支中单独执行此操作。 通常，您可以通过始终将更改合并到主干中来使其与主干保持同步，这使得完成后更容易重新集成（合并回主干）。
另请注意，我在这里使用的版本控制方案只是众多版本控制方案之一。 有些团队会做错误修复/维护版本为 1.1、1.2 等，重大更改为 1.x、2.x 等。这里的用法是相同的，但你可以将分支命名为“1”或“1” .x”而不是“1.0”或“1.0.x”。 （此外，语义版本控制是关于如何进行版本号的一个很好的指南）。
First of all, as @AndrewFinnell and @KenLiu point out, in SVN the directory names themselves mean nothing -- "trunk, branches and tags" are simply a common convention that is used by most repositories. Not all projects use all of the directories (it's reasonably common not to use "tags" at all), and in fact, nothing is stopping you from calling them anything you'd like, though breaking convention is often confusing.
I'll describe probably the most common usage scenario of branches and tags, and give an example scenario of how they are used.
Trunk: The main development area. This is where your next major release of the code lives, and generally has all the newest features.
Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.
Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code. As I said earlier, tags are often omitted and instead, a changelog or other document clarifies the revision number when a release is made.
For example, let's say you start a new project. You start working in "trunk", on what will eventually be released as version 1.0.
Once 1.0.0 is finished, you branch trunk into a new "1.0" branch, and create a "1.0.0" tag. Now work on what will eventually be 1.1 continues in trunk.
You come across some bugs in the code, and fix them in trunk, and then merge the fixes over to the 1.0 branch. You can also do the opposite, and fix the bugs in the 1.0 branch and then merge them back to trunk, but commonly projects stick with merging one-way only to lessen the chance of missing something. Sometimes a bug can only be fixed in 1.0 because it is obsolete in 1.1. It doesn't really matter: you only want to make sure that you don't release 1.1 with the same bugs that have been fixed in 1.0.
Once you find enough bugs (or maybe one critical bug), you decide to do a 1.0.1 release. So you make a tag "1.0.1" from the 1.0 branch, and release the code. At this point, trunk will contain what will be 1.1, and the "1.0" branch contains 1.0.1 code. The next time you release an update to 1.0, it would be 1.0.2.
Eventually you are almost ready to release 1.1, but you want to do a beta first. In this case, you likely do a "1.1" branch, and a "1.1beta1" tag. Now, work on what will be 1.2 (or 2.0 maybe) continues in trunk, but work on 1.1 continues in the "1.1" branch.
Once you release 1.1 final, you do a "1.1" tag from the "1.1" branch.
You can also continue to maintain 1.0 if you'd like, porting bug fixes between all three branches (1.0, 1.1, and trunk). The important takeaway is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.
Another use of branches is for features. This is where you branch trunk (or one of your release branches) and work on a new feature in isolation. Once the feature is completed, you merge it back in and remove the branch.
The idea of this is when you're working on something disruptive (that would hold up or interfere with other people from doing their work), something experimental (that may not even make it in), or possibly just something that takes a long time (and you're afraid if it holding up a 1.2 release when you're ready to branch 1.2 from trunk), you can do it in isolation in branch. Generally you keep it up to date with trunk by merging changes into it all the time, which makes it easier to re-integrate (merge back to trunk) when you're finished.
Also note, the versioning scheme I used here is just one of many. Some teams would do bug fix/maintenance releases as 1.1, 1.2, etc., and major changes as 1.x, 2.x, etc. The usage here is the same, but you may name the branch "1" or "1.x" instead of "1.0" or "1.0.x". (Aside, semantic versioning is a good guide on how to do version numbers).
除了 Nick 所说的之外，您还可以在 Streamed Lines: Branching Patterns for Parallel Software Development 中了解更多信息
图中
main是主干，rel1-maint是一个分支，1.0是一个标签。In addition to what Nick has said you can find out more at Streamed Lines: Branching Patterns for Parallel Software Development
In this figure
mainis the trunk,rel1-maintis a branch and1.0is a tag.一般来说（与工具无关的观点），分支是用于并行开发的机制。 一个 SCM 可以有 0 到 n 个分支。 Subversion 有 0。
Trunk 是一个主分支Subversion推荐，但您绝不会被迫创建它。 您可以将其称为“main”或“releases”，或者根本没有！
分支代表开发工作。 它永远不应该以资源（如“vonc_branch”）命名，而应以：
问题是标签和分支在颠覆。 我肯定会推荐偏执的方法：
<块引用>
您可以使用 Subversion 提供的访问控制脚本之一来阻止任何人执行除在标签区域中创建新副本之外的任何操作。
标签是最终的。 它的内容永远不应该改变。 绝不。 曾经。 您忘记了发行说明中的一行吗？ 创建一个新标签。 废弃或删除旧的。
现在，我读了很多关于“在这样那样的分支中合并回来这样那样的内容，然后最终合并到主干分支中”。
这称为合并工作流程，并且此处没有任何强制要求。 并不是因为您有主干分支，您就必须合并回任何内容。
按照惯例，主干分支可以代表开发的当前状态，但这是针对一个简单的顺序项目，该项目具有：
因为在其中一个（或全部）场景中，您会得到四个“主干” ，四个“当前开发”，并且并非您在这些并行开发中所做的所有操作都必须合并回“主干”中。
In general (tool agnostic view), a branch is the mechanism used for parallel development. An SCM can have from 0 to n branches. Subversion has 0.
Trunk is a main branch recommended by Subversion, but you are in no way forced to create it. You could call it 'main' or 'releases', or not have one at all!
Branch represents a development effort. It should never be named after a resource (like 'vonc_branch') but after:
Tag is a snapshot of files in order to easily get back to that state.
The problem is that tag and branch is the same in Subversion. And I would definitely recommend the paranoid approach:
A tag is final. Its content should never change. NEVER. Ever. You forgot a line in the release note? Create a new tag. Obsolete or remove the old one.
Now, I read a lot about "merging back such and such in such and such branches, then finally in the trunk branch".
That is called merge workflow and there is nothing mandatory here. It is not because you have a trunk branch that you have to merge back anything.
By convention, the trunk branch can represent the current state of your development, but that is for a simple sequential project, that is a project which has:
Because with one (or all) of those scenario, you get yourself four 'trunks', four 'current developments', and not all you do in those parallel development will necessarily have to be merged back in 'trunk'.
在 SVN 中，标签和分支非常相似。
标签 = 定义的时间片段，通常用于发布
分支 = 也是可以继续开发的定义的时间片段，通常用于主要版本，如 1.0、1.5、 2.0 等，然后当您发布时标记分支。 这使您能够继续支持生产版本，同时在主干
主干 = 开发工作空间中进行重大更改，这是所有开发应该发生的地方，然后从分支版本合并回更改。
In SVN a tag and branch are really similar.
Tag = a defined slice in time, usually used for releases
Branch = also a defined slice in time that development can continue on, usually used for major version like 1.0, 1.5, 2.0, etc, then when you release you tag the branch. This allows you to continue to support a production release while moving forward with breaking changes in the trunk
Trunk = development work space, this is where all development should happen, and then changes merged back from branch releases.
它们实际上没有任何正式含义。 文件夹就是文件夹
到SVN。 它们是一种普遍接受的组织项目的方式。
主干是你保持主线发展的地方。 分支文件夹是您可以创建分支的地方，这很难在简短的文章中解释清楚。
分支是您与主干分开处理的项目子集的副本。 也许它是用于可能不会进行任何地方的实验，或者也许是为了下一个版本，当它变得稳定时，您稍后会将其合并回主干。
标签文件夹用于创建存储库的标记副本，通常在发布检查点。
标签
但就像我说的，对于 SVN，文件夹就是文件夹。
branch、trunk和 tag 只是一种约定。我随意使用“复制”这个词。 SVN 实际上并不制作存储库中内容的完整副本。
They don't really have any formal meaning. A folder is a folder
to SVN. They are a generally accepted way to organize your project.
The trunk is where you keep your main line of developmemt. The branch folder is where you might create, well, branches, which are hard to explain in a short post.
A branch is a copy of a subset of your project that you work on separately from the trunk. Maybe it's for experiments that might not go anywhere, or maybe it's for the next release, which you will later merge back into the trunk when it becomes stable.
And the tags folder is for creating tagged copies of your repository, usually at release checkpoints.
But like I said, to SVN, a folder is a folder.
branch,trunkand tag are just a convention.I'm using the word 'copy' liberally. SVN doesn't actually make full copies of things in the repository.
主干是保存最新源代码和功能的开发线。 它应该包含最新的错误修复以及添加到项目中的最新功能。
分支通常用于远离主干（或其他开发线）执行某些操作，否则会破坏构建。 新功能通常构建在分支中，然后合并回主干中。 分支通常包含不一定被其分支的开发线批准的代码。 例如，程序员可以尝试对分支中的某些内容进行优化，只有在优化令人满意后才合并回开发线。
标签是存储库在特定时间的快照。 这些方面不应有任何进展。 它们最常用于获取发布给客户端的内容的副本，以便您可以轻松访问客户端正在使用的内容。
这是一个非常好的存储库指南的链接：
维基百科中的文章是也值得一读。
The trunk is the development line that holds the latest source code and features. It should have the latest bug fixes in it as well as the latest features added to the project.
The branches are usually used to do something away from the trunk (or other development line) that would otherwise break the build. New features are often built in a branch and then merged back into the trunk. Branches often contain code that are not necessarily approved for the development line it branched from. For example, a programmer could try an optimization on something in a branch and only merge back in the development line once the optimization is satisfactory.
The tags are snapshots of the repository at a particular time. No development should occur on these. They are most often used to take a copy of what was released to a client so that you can easily have access to what a client is using.
Here's a link to a very good guide to repositories:
The articles in Wikipedia are also worth reading.
这就是软件开发的问题，任何事情都没有一致的知识，每个人似乎都有自己的方式，但那是因为它无论如何都是一个相对年轻的学科。
这是我简单的方法，
trunk - trunk 目录包含最新的、经过批准的和合并的工作主体。 与许多人所承认的相反，我的后备箱仅用于干净、整洁、经过批准的工作，而不是开发区域，而是发布区域。
在某个给定的时间点，当主干似乎已准备好释放时，它就会被标记并释放。
branches - 分支目录包含实验和正在进行的工作。 分支下的工作会一直保留在那里，直到被批准合并到主干中为止。 对我来说，这是完成所有工作的区域。
例如：我可以有一个 iteration-5 分支用于产品的第五轮开发，也许有一个 prototype-9 分支用于第九轮实验，等等在。
tags - 标签目录包含已批准的分支和主干版本的快照。 每当分支被批准合并到主干，或者主干发布时，都会在标签下创建批准的分支或主干版本的快照。
我想有了标签，我可以很容易地在时间中来回跳转到感兴趣的点。
Now that's the thing about software development, there's no consistent knowledge about anything, everybody seems to have it their own way, but that's because it is a relatively young discipline anyway.
Here's my plain simple way,
trunk - The trunk directory contains the most current, approved, and merged body of work. Contrary to what many have confessed, my trunk is only for clean, neat, approved work, and not a development area, but rather a release area.
At some given point in time when the trunk seems all ready to release, then it is tagged and released.
branches - The branches directory contains experiments and ongoing work. Work under a branch stays there until is approved to be merged into the trunk. For me, this is the area where all the work is done.
For example: I can have an iteration-5 branch for a fifth round of development on the product, maybe a prototype-9 branch for a ninth round of experimenting, and so on.
tags - The tags directory contains snapshots of approved branches and trunk releases. Whenever a branch is approved to merge into the trunk, or a release is made of the trunk, a snapshot of the approved branch or trunk release is made under tags.
I suppose with tags I can jump back and forth through time to points interest quite easily.
当我查找 作者 的网站时，我发现了这个关于 SVN 的很棒的教程： //en.wikipedia.org/wiki/OpenCV" rel="noreferrer">OpenCV 2 计算机视觉应用程序编程手册，我认为我应该分享。
他有一个关于如何使用 SVN 以及短语“trunk”、“tag”和“branch”含义的教程。
直接引用他的教程：
I found this great tutorial regarding SVN when I was looking up the website of the author of the OpenCV 2 Computer Vision Application Programming Cookbook and I thought I should share.
He has a tutorial on how to use SVN and what the phrases 'trunk', 'tag' and 'branch' mean.
Cited directly from his tutorial:
trunk 目录是您可能最熟悉的目录，因为它用于保存最近的更改。 您的主要代码库应该位于主干中。
分支目录用于保存您的分支，无论它们是什么。
标签目录基本上用于标记一组特定的文件。 您可以对发布之类的内容执行此操作，您希望“1.0”是这些修订版中的这些文件，而“1.1”是这些修订版中的这些文件。 标签一旦制作完成，您通常不会对其进行修改。 有关标签的更多信息，请参阅第 4 章。分支和合并（在使用 Subversion 进行版本控制< /a>）。
The trunk directory is the directory that you're probably most familiar with, because it is used to hold the most recent changes. Your main codebase should be in trunk.
The branches directory is for holding your branches, whatever they may be.
The tags directory is basically for tagging a certain set of files. You do this for things like releases, where you want "1.0" to be these files at these revisions and "1.1" to be these files at these revisions. You usually don't modify tags once they're made. For more information on tags, see Chapter 4. Branching and Merging (in Version Control with Subversion).
每个人的定义略有不同的原因之一是因为 Subversion 对分支和标签实现了零支持。 Subversion 基本上是这样说的：我们查看了其他系统中功能齐全的分支和标签，但没有发现它们有用，因此我们没有实现任何东西。 只需将副本复制到具有名称约定的新目录中即可。 当然，每个人都可以自由地制定略有不同的惯例。 了解真实标签与纯粹的复制+命名约定之间的区别
请参阅 Wikipedia 条目 Subversion 标记和内容 分支。
One of the reasons why everyone has a slightly different definition is because Subversion implements zero support for branches and tags. Subversion basically says: We looked at full-featured branches and tags in other systems and did not found them useful, so we did not implement anything. Just make a copy into a new directory with a name convention instead. Then of course everyone is free to have slightly different conventions. To understand the difference between a real tag and a mere copy + naming convention
see the Wikipedia entry Subversion tags & branches.
我认为这就是“标签”的典型含义。 但在颠覆中：
我发现这相当令人困惑：一个对分支或标签一无所知的版本控制系统。 从实现的角度来看，我认为 Subversion 创建“副本”的方式非常聪明，但我必须了解它，我称之为 泄漏抽象。
或者也许我只是使用 CVS 太久了。
I think this is what one typically means by "tag". But in Subversion:
which I find rather confusing: a revision control system that knows nothing about branches or tags. From an implementation point of view, I think the Subversion way of creating "copies" is very clever, but me having to know about it is what I'd call a leaky abstraction.
Or perhaps I've just been using CVS far too long.
我认为一些混乱来自于标签的概念和 SVN 中的实现之间的差异。 对于 SVN 来说，标签是一个分支，也是一个副本。 修改标签被认为是错误的，事实上，如果您尝试修改路径中带有 ../tags/.. 的任何内容，TortoiseSVN 等工具会向您发出警告。
I think that some of the confusion comes from the difference between the concept of a tag and the implementation in SVN. To SVN a tag is a branch which is a copy. Modifying tags is considered wrong and in fact tools like TortoiseSVN will warn you if you attempt to modify anything with ../tags/.. in the path.
我不太确定“标签”是什么，但分支是一个相当常见的源代码控制概念。
基本上，分支是一种在不影响主干的情况下更改代码的方法。 假设您要添加一个相当复杂的新功能。 您希望能够在进行更改时签入更改，但在完成该功能之前不希望它影响主干。
首先你要创建一个分支。 这基本上是您创建分支时主干的副本。 然后你就可以在分支机构完成所有工作。 分支中所做的任何更改都不会影响主干，因此主干仍然可用，允许其他人继续在那里工作（例如进行错误修复或小型增强）。 一旦你的功能完成，你就可以将分支集成回主干。 这会将所有更改从分支移动到主干。
人们使用多种模式来表示分支。 如果您的产品同时支持多个主要版本，通常每个版本都是一个分支。 在我工作的地方，我们有一个质量检查部门和一个生产部门。 在将代码发布到 QA 之前，我们将更改集成到 QA 分支，然后从那里进行部署。 当发布到生产时，我们从 QA 分支集成到生产分支，因此我们知道生产中运行的代码与 QA 测试的代码相同。
这是分支上的维基百科条目，因为它们可能比我解释得更好。 :)
I'm not really sure what 'tag' is, but branch is a fairly common source control concept.
Basically, a branch is a way to work on changes to the code without affecting trunk. Say you want to add a new feature that's fairly complicated. You want to be able to check in changes as you make them, but don't want it to affect trunk until you're done with the feature.
First you'd create a branch. This is basically a copy of trunk as-of the time you made the branch. You'd then do all your work in the branch. Any changes made in the branch don't affect trunk, so trunk is still usable, allowing others to continue working there (like doing bugfixes or small enhancements). Once your feature is done you'd integrate the branch back into trunk. This would move all your changes from the branch to trunk.
There are a number of patterns people use for branches. If you have a product with multiple major versions being supported at once, usually each version would be a branch. Where I work we have a QA branch and a Production branch. Before releasing our code to QA we integrate changes to the QA branch, then deploy from there. When releasing to production we integrate from the QA branch to the Production branch, so we know the code running in production is identical to what QA tested.
Here's the Wikipedia entry on branches, since they probably explain things better than I can. :)
主干：在敏捷的每个冲刺完成后，我们都会推出部分可交付的产品。 这些版本保存在主干中。
分支：每个正在进行的冲刺的所有并行开发代码都保存在分支中。
标签：每次我们发布部分可交付的产品类型的测试版时，我们都会为其创建一个标签。 这为我们提供了当时可用的代码，允许我们在开发过程中的某个时刻需要时返回到该状态。
Trunk : After the completion of every sprint in agile we come out with a partially shippable product. These releases are kept in trunk.
Branches : All parallel developments codes for each ongoing sprint are kept in branches.
Tags : Every time we release a partially shippable product kind of beta version, we make a tag for it. This gives us the code that was available at that point of time, allowing us to go back at that state if required at some point during development.
对于熟悉GIT的人来说，GIT中的master就相当于SVN中的trunk。
分支和标签在 GIT 和 SVN 中具有相同的术语。
For people familiar with GIT, master in GIT is equivalent to trunk in SVN.
Branch and tag has same terminology in both GIT and SVN.
嗯，不确定我是否同意尼克重新标记类似于分支。 标签只是一个标记
Trunk将是开发的主体，从项目开始到现在。
分支将是从主干中某个点派生的代码副本，用于对代码进行重大更改，同时保留主干中代码的完整性。 如果主要变更按计划进行，它们通常会合并回主干。
标签将是您希望保留的树干或树枝上的一个时间点。 保留的两个主要原因是，要么这是软件的主要版本，无论是 alpha、beta、RC 还是 RTM，要么这是应用主干重大修订之前软件最稳定的点。
在开源项目中，不被项目利益相关者接受到主干中的主要分支可以成为分叉的基础——例如，与其他源代码共享共同起源的完全独立的项目。
分支和标签子树与主干的区别如下：
Subversion 允许系统管理员创建挂钩脚本，当某些事件发生时，这些脚本将被触发执行； 例如，向存储库提交更改。 对于典型的 Subversion 存储库实现来说，将任何包含“/tag/”的路径在创建后进行写保护是很常见的； 最终结果是，标签一旦创建，就是不可变的（至少对于“普通”用户而言）。 这是通过钩子脚本完成的，如果 tag 是已更改对象的父节点，则钩子脚本会通过防止进一步更改来强制不变性。
从 1.5 版开始，Subversion 还添加了与“分支合并跟踪”相关的功能，以便可以将提交到分支的更改合并回主干，并支持增量、“智能”合并。
Hmm, not sure I agree with Nick re tag being similar to a branch. A tag is just a marker
Trunk would be the main body of development, originating from the start of the project until the present.
Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
Tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.
In open source projects, major branches that are not accepted into the trunk by the project stakeholders can become the bases for forks -- e.g., totally separate projects that share a common origin with other source code.
The branch and tag subtrees are distinguished from the trunk in the following ways:
Subversion allows sysadmins to create hook scripts which are triggered for execution when certain events occur; for instance, committing a change to the repository. It is very common for a typical Subversion repository implementation to treat any path containing "/tag/" to be write-protected after creation; the net result is that tags, once created, are immutable (at least to "ordinary" users). This is done via the hook scripts, which enforce the immutability by preventing further changes if tag is a parent node of the changed object.
Subversion also has added features, since version 1.5, relating to "branch merge tracking" so that changes committed to a branch can be merged back into the trunk with support for incremental, "smart" merging.