I recommend the following layout, for two reasons: - all stuff related to a given project is within the same part of the tree; makes it easier for people to grasp - permissions handling may be easier this way
And by the way: It's a good idea with few repositories, instead of many, because change history normally is better preserved that way (change history is gone if you move files between repositories, unless you take special and somewhat complicated action). In most setups, there should only be two repositories: the main repository, and a sandbox repository for people experimenting with Subversion.
Taking off from what others have said, we have a rather rigid structure of progression from alpha, to beta, to production. The alpha code is whatever the head of the trunk is, and is kept stable for the most part, but not always. When we are ready to release, we create a "release branch" that effectively freezes that code, and only bug fixes are applied to it. (These are ported back into the trunk). Also, tags are periodically made as release candidates, and these are the beta versions. Once the code moves to production, the release branch is kept open for support, security, and bug-fixing, and minor versions are tagged and release off of this.
Once a particular version is no longer supported, we close the branch. This allows us to have a clear distinction of what bugs were fixed for what releases, and then they get moved into the trunk.
Major, long-term, or massive changes that will break the system for long periods of time are also given their own branch, but these are much shorter-lived, and don't have the word "release" in them.
一旦您的 DVD 被按下或您的下载包上传，您还可以做的就是将发布分支标记为已发布，这样您就可以在以后需要时轻松地从完全相同的修订版进行重建。
卡尔
When we want to prepare for the release of, say, version 3.1, we create a branches/3.1-Release branch, and merge individual commits from trunk as we seem fit (our release-branches usually only receive the most critical fixes from the main development branch).
Typically, this release branch lives through the alpha- and beta- testing phases, and is closed when the next release is on the threshold.
What you can also do, once your DVDs are pressed or your download package uploaded, is to tag the release branch as released, so you can easily rebuild from exactly the same revision if you need to later.
Where I work, we have "temp-branches" and "release-branches" directories instead of just "branches". So in your case project branches would go under temp-branches, and release branches (created at time of release, of course) would go under release-branches.
Another important consideration is when to branch and when to close a branch -- which depends on your release schedule but also how long it takes you to test and release. In my experience this takes a lot of management in terms of ensuring everyone in the team knows what the plan is and when to use what, all of which was helped by documeting it all in a release wiki.
Not quite the answer you are looking for but I think once you have the structure sorted, for which you've had plenty of good suggestions already, the next challenge is keeping the team informed and on track.
发布评论
评论（7）
我推荐以下布局，原因有二：
- 与给定项目相关的所有内容都位于树的同一部分； 使
人们更容易掌握
- 这样权限处理可能会更容易顺便
说一句：使用很少的存储库而不是很多存储库是一个好主意，因为更改历史记录通常可以更好地以这种方式保存（如果您在存储库之间移动文件，则更改历史记录将消失，除非您采取特殊的方式）以及有些复杂的动作）。 在大多数设置中，应该只有两个存储库：主存储库和供人们试验 Subversion 的沙箱存储库。
I recommend the following layout, for two reasons:
- all stuff related to a given project is within the same part of the tree; makes
it easier for people to grasp
- permissions handling may be easier this way
And by the way: It's a good idea with few repositories, instead of many, because change history normally is better preserved that way (change history is gone if you move files between repositories, unless you take special and somewhat complicated action). In most setups, there should only be two repositories: the main repository, and a sandbox repository for people experimenting with Subversion.
从其他人所说的出发，我们有一个相当严格的从 alpha 到 beta 到生产的进展结构。 阿尔法代码是无论树干的头部是什么，并且在大多数情况下保持稳定，但并非总是如此。 当我们准备好发布时，我们创建一个“发布分支”，有效地冻结该代码，并且仅对其应用错误修复。 （这些被移植回主干）。 此外，还会定期制作标签作为候选版本，这些是测试版本。 一旦代码转移到生产环境，发布分支将保持开放以提供支持、安全性和错误修复，并且次要版本将被标记并从中发布。
一旦不再支持某个特定版本，我们就会关闭该分支。 这使我们能够清楚地区分哪些版本修复了哪些错误，然后将它们移动到主干中。
会在很长一段时间内破坏系统的主要、长期或大规模的变化也有自己的分支，但这些变化的寿命要短得多，并且其中没有“发布”这个词。
Taking off from what others have said, we have a rather rigid structure of progression from alpha, to beta, to production. The alpha code is whatever the head of the trunk is, and is kept stable for the most part, but not always. When we are ready to release, we create a "release branch" that effectively freezes that code, and only bug fixes are applied to it. (These are ported back into the trunk). Also, tags are periodically made as release candidates, and these are the beta versions. Once the code moves to production, the release branch is kept open for support, security, and bug-fixing, and minor versions are tagged and release off of this.
Once a particular version is no longer supported, we close the branch. This allows us to have a clear distinction of what bugs were fixed for what releases, and then they get moved into the trunk.
Major, long-term, or massive changes that will break the system for long periods of time are also given their own branch, but these are much shorter-lived, and don't have the word "release" in them.
当我们想要准备发布 3.1 版本时，我们创建一个 Branches/3.1-Release 分支，并根据需要合并主干中的各个提交（我们的发布分支通常只从主分支接收最关键的修复）开发分支）。
通常，此发布分支会经历 alpha 和 beta 测试阶段，并在下一个版本即将发布时关闭。
一旦您的 DVD 被按下或您的下载包上传，您还可以做的就是将发布分支标记为已发布，这样您就可以在以后需要时轻松地从完全相同的修订版进行重建。
卡尔
When we want to prepare for the release of, say, version 3.1, we create a branches/3.1-Release branch, and merge individual commits from trunk as we seem fit (our release-branches usually only receive the most critical fixes from the main development branch).
Typically, this release branch lives through the alpha- and beta- testing phases, and is closed when the next release is on the threshold.
What you can also do, once your DVDs are pressed or your download package uploaded, is to tag the release branch as released, so you can easily rebuild from exactly the same revision if you need to later.
Carl
我们已经使用标签，尽管我们有一个大项目结构而不是您概述的许多小项目。
在这种情况下，我们需要标记，例如 1.0.0，但也需要分支，例如 1.0。 我关心的是将项目分支和发布分支混合在一起，例如
We already use tags, although we have the one-big-project structure rather than the many-small-projects you have outlined.
In this case, we need to tag, e.g. 1.0.0, but also branch, e.g. 1.0. My concern is mixing project branches and release branches together, e.g.
在我工作的地方，我们有“temp-branches”和“release-branches”目录，而不仅仅是“branches”。 因此，在您的情况下，项目分支将位于临时分支下，而发布分支（当然是在发布时创建的）将位于发布分支下。
Where I work, we have "temp-branches" and "release-branches" directories instead of just "branches". So in your case project branches would go under temp-branches, and release branches (created at time of release, of course) would go under release-branches.
另一个重要的考虑因素是何时进行分支以及何时关闭分支——这取决于您的发布时间表以及测试和发布所需的时间。 根据我的经验，这需要大量的管理来确保团队中的每个人都知道计划是什么以及何时使用什么，所有这些都通过在发布 wiki 中记录所有内容来帮助。
这并不完全是您正在寻找的答案，但我认为一旦您对结构进行了排序，并且您已经为此提出了很多好的建议，下一个挑战就是让团队了解情况并走上正轨。
Another important consideration is when to branch and when to close a branch -- which depends on your release schedule but also how long it takes you to test and release. In my experience this takes a lot of management in terms of ensuring everyone in the team knows what the plan is and when to use what, all of which was helped by documeting it all in a release wiki.
Not quite the answer you are looking for but I think once you have the structure sorted, for which you've had plenty of good suggestions already, the next challenge is keeping the team informed and on track.
发布与标签相同...您的主干中有多个项目吗？ 在这种情况下，我会在标签内复制相同的文件夹
所以
Releases is the same as tags... Have you got multiple projects inside your trunk? In that case, I would copy the same folders inside tags
So