我将负责决定如何在我们的 CVS/SVN 存储库中进行标记分支。
是否有任何文献可以帮助我了解使用 CVS 的最佳方式?分支/标记等?
谢谢
我将负责决定如何在我们的 CVS/SVN 存储库中进行标记分支。
是否有任何文献可以帮助我了解使用 CVS 的最佳方式?分支/标记等?
谢谢
我在 FreeBSD 项目的 10 多年 CVS 中的个人经验是:尽可能快地切换到其他东西。CVS 是面向文件的而不是面向快照/变更集的,这使得分支之间的合并相当痛苦。无论如何,CVS 的分支都很痛苦。
至于 CVS 的资源,请参阅CVS 主页
如果您想谈论 SVN,我建议您阅读 SVN Book和 this question。
我建议阅读关于 SVN 和 CVS 的两本实用程序员书籍,名为“使用 CVS 的实用版本控制”和“使用 Subversion 的实用版本控制”。
两者都是极好的资源,充满了描述你想要做什么的食谱,而不是前面提到的书中对技术本身的具体细节描述。
高温高压
干杯,
抢
明智的经验法则:
通常,您需要对已发布的版本进行分支,以便测试和发布补丁。您可能有其他原因进行分支。
使用 Subversion 肯定会更好。
我推荐你在 Windows上使用SVN ,在 Linux上使用Git 。不要使用 CVS,恕我直言,这太糟糕了。
SVN Book是您首先需要的。
标记每个公共构建(发布)。由于某种原因,分支是一个复制主干 - 例如另一种开发方式。每次需要时分支存储库:)
我相信这是来自编码恐惧:
Chris Birmele 的关于分支和合并的论文是我发现的对这一重要源代码控制任务的最佳介绍。分支的方法有几十种,没有一种正确的方法可以做到。熟悉您的选项,以便了解每个选项的权衡。
Eric Sink 的 Source Control HOWTO后面的条目涵盖了分支和合并。
如果你想要一个 10 的启动器进行颠覆:
将“主干”视为您开发的完整历史。任何被释放的东西都必须在某个时间点以某种形式出现在主干中。
在复杂的开发任务中使用开发分支(主干的分支)。任务完成后,使用重新集成合并将更改从分支拉到主干。这样,您可以对主干进行一些特定的提交,而不是与同一任务相关的许多提交。不再需要时删除这些开发分支。将它们命名为“FeatureX”
使用版本分支(再次来自主干)来管理注定要发布给客户/部署到生活的营销版本。版本是主干中修订的子集。要使用它们,请在适当的修订版(可能不是 head)从主干分支,手动记录来自主干的修订作为合并到该分支,合并您需要从主干(仅来自主干)的任何其他修订。不要直接开发到版本分支,只从主干合并 - 尽管合并可能需要额外的工作以使其与版本兼容。名称如“2.4 版”
每当您制作发布给客户或部署到现场的构建或修补程序时,从您的版本分支创建特定标签。名称如“2.4.1”、“2.4.2”等。
以这种方式工作,您可以使用 subversion 的合并跟踪(1.5 版及更高版本)来准确查看每个版本中每个标签中的内容。为此,请获取标签或版本分支的工作副本并执行 'svn mergeinfo --show-revs merge http://svn/trunk c:\workingcopy\'
这对于审核员、自动生成的发布说明、测试人员以及您对确切内容和内容的信心非常有用。使用包含此信息的自动生成矩阵,一目了然地查看不同版本包含的内容。
你应该离开 CVS。CVS 是旧的并且在分支/标记方面不是很快(分支/标记的创建线性依赖于项目中的文件数量)
你应该首先考虑你的分支策略:你想拥有一个
这在很大程度上取决于您的项目和开发理念
如果你想使用 SVN,你真的必须考虑你的存储库布局,因为几乎所有的软件项目都是基于模块的,你应该找到一个可以轻松标记所有需要的模块的结构。SVN 及其基于文件夹的分支/标签方法很难实现这一要求。
这应该很清楚,多存储库布局更难以维护稳定的标记系统。我更喜欢“标记所有”的方法,但这是我个人的选择。
几年前去我的第一个真正的 SCM(从源代码安全)时,我发现以下内容很有帮助 - 当时我认为 perforce 有一份白皮书:
Cederqvist通常被认为是CVS的指南。
我建议使用 GIT,因为标记/分支过程非常易于使用。使用 SVN(尤其是在 windows 上)的好处是 GUI 工具的数量和 windows shell 的集成。
我还支持关于 SVN 的实用程序员书籍的推荐。
好吧,你使用什么源代码控制系统并不重要,它们基本上都遵循某种形式的主干/分支/标签结构。即使它是一个分布式模型,存储库也会以反映这一点的方式设置。
有一个非常简单的解释可以帮助您从这里开始。