分支和标记的 CVS/SVN 最佳实践
我将负责决定在我们的 CVS/SVN 存储库中如何进行标记分支。
是否有任何文献可以帮助我了解使用 CVS 的最佳方式？ 分支/标记等？
谢谢
i'm going to be responsible for deciding how tagging branching is going to happen in our CVS/SVN repo.
Is there any literature that will help me understand the best way to work with CVS? either branching/tagging, etc?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
我在 FreeBSD 项目中使用 CVS 十多年的个人经验是：尽快切换到其他东西。 CVS 是面向文件的，而不是面向快照/变更集的，这使得分支之间的合并相当痛苦。 无论如何，分支对于 CVS 来说都是痛苦的。
至于 CVS 的资源请参见 CVS Home
如果你想谈论 SVN，我会建议SVN Book本身和这问题。
My personal experience during more than 10 years of CVS at the FreeBSD project is: switch to something else as fast as you can. CVS is file oriented not snapshot/changeset oriented which makes merging beween branches rather painful. Branches are painful with CVS anyway.
As for resources for CVS see CVS Home
If you want to talk about SVN, I'd suggest the SVN Book itself and this question.
我建议阅读两本关于 SVN 和 CVS 的实用程序员书籍，名为“使用 CVS 进行实用版本控制" 和 "使用 Subversion 进行实用的版本控制”。
这两本书都是优秀的资源，其中充满了描述您想要做什么的秘诀，而不是前面提到的书籍中对技术本身的具体描述。
HTH
干杯，
罗布
I'd recommend reading the two Pragmatic Programmer books on SVN and CVS called "Pragmatic Version Control Using CVS" and "Pragmatic Version Control Using Subversion".
Both are excellent resources full of recipes describing what you want to do rather than the nuts and bolts descriptions of technology itself in the books previously mentioned.
HTH
cheers,
Rob
我建议您在 Windows 上使用 SVN，在 Linux 上使用 Git。 不要使用 CVS，恕我直言，这很糟糕。
SVN Book 是您首先需要的。
标记每个公共构建（发布）。 出于某种原因，分支是复制主干 - 例如另一种开发方式。 每当您需要时分支存储库:)
I recommend you SVN on Windows, Git on Linux. Don't use CVS, imho it's terrible.
SVN Book is that what you need first.
Tag every public build (release). Branch is a copying out trunk for some reason - e.g. another way of development. Branch repository everytime when you need :)
我相信这是来自编码恐怖：
Chris Birmele 的关于分支和合并的论文是我发现的对这一基本源代码控制任务的最佳介绍。 分支的方法有很多种，但没有一种正确的方法。 熟悉您的选择，这样您就知道每个选择的权衡是什么。
分支和合并入门
I believe this is from coding horror:
Chris Birmele's paper on Branching and Merging is the best introduction I've found to this essential source control task. There are dozens of ways to branch, and no one correct way to do it. Get familar with your options so you know what the tradeoffs are with each one.
Branching and Merging Primer
明智的经验规则：
通常您需要对已发布的版本进行分支，以便可以测试和发布补丁。 您可能还有其他原因进行分支。
使用 Subversion 肯定会更好。
Sensible rules of thumb:
Usually you need to branch released versions so you can test and release patches. You might have other reasons for branching.
And you're definitely better off with Subversion.
Eric Sink 的源代码控制 HOWTO 中的后续条目涵盖了分支和合并。
The later entries in Eric Sink's Source Control HOWTO cover branching and merging.
如果你想要一个 10 的入门颠覆：
将“主干”视为你发展的完整历史。 所有被释放的东西都必须在某个时刻以某种形式出现在主干中。
在复杂的开发任务中使用开发分支（主干的分支）。 任务完成后，使用重新集成合并将更改从分支拉入主干。 这样，您就可以对主干进行一些特定的提交，而不是与同一任务相关的许多提交。 当不再需要时删除这些开发分支。 将它们命名为“FeatureX”，
使用版本分支（同样来自主干）来管理注定要发布给客户/部署上线的营销版本。 版本是主干中修订的子集。 要使用它们，请从主干的适当修订（可能不是头部）分支，手动记录主干的修订合并到该分支，从主干合并您需要的任何其他修订（仅从主干）。 不要直接开发到版本分支，只能从主干合并 - 尽管合并可能需要额外的工作才能使其与版本兼容。 名称如“版本 2.4”
每当您制作要发布给客户或部署到实时版本的构建或修补程序时，请从版本分支创建特定标签。 名称如“2.4.1”、“2.4.2”等。
通过这种方式，您可以使用 Subversion 的合并跟踪（版本 1.5 及更高版本）来准确查看每个修订版本中每个标签的内容。 为此，请获取标签或版本分支的工作副本，然后执行 'svn mergeinfo --show-revs merged http://svn /trunk c:\workingcopy\'
这对于审核员、自动生成的发行说明、测试人员以及您对新内容和新内容的信心非常有用。 使用包含此信息的自动生成的矩阵，可以一目了然地查看不同版本包含的内容。
If you want a starter for 10 for subversion:
Treat 'trunk' as a complete history of your development. Everything that ever gets released must appear in trunk at some point and in some form.
Use development branches(branches from trunk) in complicated development tasks. When task is finished, use re-integrate merge to pull changes from the branch into trunk. This way you have a few specific commits to trunk instead of many commits all related to the same task. Delete these development branches when no-longer needed. Name them like 'FeatureX'
Use version branches(again from trunk) to manage marketing versions which are destined to get released to customers/deployed to live. A version is a subset of the revisions in trunk. To use them, branch from trunk at an appropriate revision (may not be head), manually record the revisions from trunk as being merged into that branch, merge in any additional revisions you need from trunk (only from trunk). Do not develop directly onto a version branch, only merge from trunk - although the merge may need extra work to make it compatible with the version. Name like 'Version 2.4'
Create specific tags from your version branches whenever you make a build or hotfix that gets released to customers or deployed into live. Name like '2.4.1', '2.4.2' etc.
Working this way you can use subversion's merge-tracking (version 1.5 and above) to see exactly what's in each tag in a revision by revision basis. To do this, get a working copy of your tag or version branch and do 'svn mergeinfo --show-revs merged http://svn/trunk c:\workingcopy\'
That's great for auditors, auto-generated release notes, testers, and your own confidence about exactly what's in and what's out. Use an auto-generated matrix with this information to see at a glance what different versions contain.
阅读此内容：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
Read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
你应该离开 CVS。 CVS 很旧，并且在分支/标记方面速度不是很快（分支/标记创建线性取决于项目中的文件数量）。
您应该首先考虑您的分支策略：您想要一个
这在很大程度上取决于您的项目和开发理念
如果您想使用SVN，您确实必须考虑您的存储库布局，因为几乎所有软件项目都是基于模块的，您应该找到您可以在其中轻松标记所有需要的模块的结构。 SVN 及其基于文件夹的分支/标签方法不容易实现此要求。
这就是说，应该清楚的是，多存储库布局更难以维护稳定的标记系统。 我更喜欢“标记全部”方法，但这是我个人的选择。
you should leave CVS. CVS is old and not very fast in terms of branching/tagging(branch/tag creation depends linearly on number of files in a project)
You should think of your branching strategy first: do you want to have a
This heavily depends on your project and development philosophy
If you want to use SVN you really have to think of your repository layout, because nearly all softwareprojects are module-based and you should find a structure in which you can easily tag all needed modules. SVN with its folderbased approach of branches/tags is not easy to achieve this requirement.
This said it should be clear, that multirepository layouts are more difficult to maintain a stable tagging system. I prefer a "tag all" approach, however this is my personal choice.
几年前，当我第一次接触真正的 SCM（来自安全来源）时，我发现以下内容很有帮助 - 当时有一份 perforce 的白皮书，我认为：
http://www.perforce.com/perforce/bestpractices.html
When going to my first real SCM (from source safe) years ago, I found the following helpful - back then there was a white paper by perforce I think:
http://www.perforce.com/perforce/bestpractices.html
Cederqvist 通常被视为 CVS 指南。
The Cederqvist is generally regarded as the guide to CVS.
我建议使用 GIT，因为标记/分支过程非常易于使用。 使用 SVN（尤其是在 Windows 上）的好处是 GUI 工具的数量和 Windows shell 集成。
我还赞同关于 SVN 的实用程序员书籍的推荐。
I'd recommend using GIT as the tagging/branching process is extremely easy to use. The benefit of using SVN (especially on windows) is the number of GUI tools and the windows shell intergration.
I also second the recommendation for the Pragmatic Programmer books on SVN.
好吧，你使用什么源代码控制系统并不重要，它们基本上都遵循某种形式的主干/分支/标签结构。 即使它是分布式模型，存储库也会以反映这一点的方式设置。
这里有一个非常简单的解释可以帮助您入门。
Well, it doesn't really matter what source control system you use, they all basically follow some form of trunk/branches/tags structure. Even if it's a distributed model, the repositories will be setup in a way to reflect that.
There is a pretty simple explanation to get you started here.