颠覆标签和分支
有没有人想出比一般推荐的更好的技术来管理颠覆中的标签和分支（称为“标签”和“分支”的并行目录）？
Has anybody come up with a better technique for managing tags and branches in subversion than what is generally recommended (the parallel directories called 'tags' and 'branches')?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用存储库名称空间来传达分支/标签等信息从根本上来说是 SVN 模型； 如果您想要的是不同的模型，那么您可能确实想要 SVN 以外的东西。
SVN 中缺少像 CVS 样式标签这样的元数据是一个有意的设计决策。 无论您在树中选择什么样的分支/标签/项目排列，它都将减少到用于每个目的的并行目录集。 剩下的就是为您的分支和标签选择正确的命名策略，以使您更清楚。
我喜欢的一个惯例是完全重量级分支和轻量级“树枝”之间的分离。 我工作的团队的惯例是，长期开发在一个分支中进行，发布工程师必须了解每个分支并对其承担部分责任，但任何工程师都可以创建一个短暂的树枝来用作临时空间对于太大而无法一次签入但又不足以需要发布工程支持的问题。 这里的 Twig 位于一个与分支类似的单独的并行“twigs”目录中，命名约定通常包含创建者的用户 ID 和 Twig 旨在解决的问题的 bug ID 号。
Using the repository namespace to convey information like branches / tags / etc is fundamentally the SVN model; if what you want is a different model, you probably really want something other than SVN.
The lack of metadata like CVS-style labels in SVN is an intentional design decision. No matter what arrangement of branches/tags/projects you choose in your tree, it's all going to reduce to sets of parallel directories for each purpose. What's left is just choosing the right naming strategy for your branches and tags to make things more clear to you.
One convention that I'm fond of is a separation between full heavyweight branches and lightweight "twigs". The convention in the group where I work is that long-lived development goes in a branch, and the release engineers must know of and be partially responsible for each branch, but that any engineer can create a short-lived twig to use as scratch space for a problem that's too large to fit into one checkin but not massive enough to require release engineering support. Twigs here live in a separate parallel 'twigs' directory similar to branches, and the naming convention often has the creator's user ID and the bug ID number for the issue the twig is intended to address in it.
我们使用“主干、标签、分支和流”策略。
“主干”是应该放置生产中的最新版本的地方。
“标记”是当流完成时发生“复制到”的地方，我们需要存储流的状态以用于存档目的。 它还允许从特定点继续开发。
“分支”是指发生与主流开发完全不同的事情。 通常，分支非常罕见。
“流”是我们最常用的。 开发流是基于任务的焦点，例如特定修复或开发工作的流（例如，变更请求的完成）。 流是允许相互合并的，但是不同的流会根据svn策略进行排名。 例如，我们有一个用于 CR 版本的流，还有另一个用于推出应用程序支持版本的流。 由于 CR 流除了自身的更改之外还必须纳入应用程序支持修复，因此它的排名更高。 排名较高的流有较低的流（根据需要）合并到其中。 最后，流就可以投入生产了。 它被标记，然后“复制到”主干，然后使用（通常，尽管有时使用标签）作为进一步流的基础。
然而，流的最佳用途是用于需要不到两周才能完成的短期任务。 这些流可以快速合并到多个更高排名的流中，然后这些流稍后合并到任何其他更高排名的流中。 例如，由于应用程序支持低于 cr，因此任何应用程序支持快速修复都可以复制到流中，然后进行处理、合并到应用程序支持，然后将其合并到 cr 流。
We use a "trunk, tag, branch and stream" strategy.
The "trunk" is where the most current version of whatever is out in production is supposed to be placed.
A "tag" is where a "copy to" occurs when a stream is complete and we need to store the status of the stream for archival purposes. It also allows development to continue from a specific point.
A "branch" is when something completely different than mainstream development is to take place. Usually, branches are very rare.
"Streams" are what we most use. A stream of development is a task-based focus, such as a stream for a particular fix or development effort (for instance, a change requests' completion). Streams are allowed to merge with each other, but different streams are ranked based on svn strategy. For instance, we had one stream for a cr release, and another stream for pushing out app support releases. Since the CR stream had to incorporate the app support fixes in addition to its own changes, it was ranked higher. Streams that are higher ranked have lower streams (as needed) merged into them. Finally, a stream becomes production-ready. It is tagged, and then "copied to" trunk, which is then used (normally, although sometimes tags are used) as the base for further streams.
The best use of streams, however, are for short tasks that take less than two weeks to complete. These streams can be merged quickly into multiple, higher ranked streams, which then get merged later into any other higher ranked streams. For example, since app support was lower than cr, any app support quick fix could be copied to a stream and then worked on, merged to app support which would then be merged to the cr stream.
除了在有分支时拥有并行目录之外，您可以做的唯一另一件事是，每当您想要在一个或另一个分支上工作时，在两个分支之间进行 SVN 切换。 也许你应该澄清你想要这个系统“更好”的地方，人们可以提出建议。
The only other thing you can do besides having parallel directories when you have Branches is to do an SVN Switch between two branches whenever you want to work on one or the other. Perhaps you should clarify what you want to be "better" about this system and people could make suggestions.