相关疑难解决方法(0)

维护代码时要遵循的最佳实践和经验法则是什么？在开发分支中只有生产就绪代码,或者开发分支中是否有未经测试的最新代码,这是一种好的做法吗？

你们如何维护开发代码和生产代码？

编辑 - 补充问题 - 您的开发团队是否遵循"尽快提交 - 通常 - 甚至是代码包含 - 次要错误或不完整"协议或"提交 - 只有完美的代码"协议,同时将代码提交给开发分支？

我们目前在相对较大的代码库上使用subversion.每个版本都有自己的分支,并对主干执行修复,并使用迁移到发布分支svnmerge.py

我相信现在是时候进行更好的源代码控制了,我一直在玩Mercurial.

虽然使用Mercurial管理这样的发布结构似乎有两个学派.每个版本都有自己的repo,并且针对发布分支进行修复并推送到主分支(以及任何其他更新的发布分支.)或在单个存储库(或多个匹配副本)中使用命名分支.

在任何一种情况下,似乎我可能会使用像移植一样的东西,以包含在发布分支中的cherrypick更改.

我问你 每种方法的相对优点是什么？

最近我从SVN切换到了Mercurial.现在我想知道如何根据良好实践在Mercurial中实现我想要的分支工作流程,希望其他开发人员了解存储库中会发生什么.

这是工作流程:

1. 通常我有一个trunk/default分支,用于处理当前版本系列.我们说这是1.x. 同时我使用分支2.x来处理下一个主要版本.此分支中的更改可能是激进的,因此与trunk/default/1.x分支合并在此处没有任何意义.
   • 一段时间后,2.x上的工作可能会完成,版本2.0会被释放.现在我希望2.x分支是新的默认/中继分支,当前默认/中继是1.x分支.
   • 重复这个过程,可能会有一个新的3.x分支.和以前一样,如果3.0被释放,3.x应该成为新的默认分支,而当前的默认值应该成为2.x分支(再次).

我的问题不是这个工作流程是否合适(我猜这不是根本错误的).我的问题是,我在Mercurial中实现这一点的方式是否可以被视为良好实践或是否有更好的机会.

所以这就是我计划在Mercurial中管理分支的方式......

从具有单个分支的存储库开始,该分支包含当前版本系列1.x的代码:

$ hg init
$ echo "hello world" > file1.txt
$ hg ci -A -m "Initial commit of 1.x code"

开始处理2.x版本:

$ hg branch 2.x
$ hg ci -m "Create new branch for 2.x development"
$ echo "Big new feature for 2.x" > file2.txt
$ hg ci -A -m "Add big new feature"

同时,在当前版本系列(1.x)中做一些工作:

$ hg up default
$ echo "Minor adjustments specific for 1.x" > file3.txt
$ hg ci …

这是一个最佳实践问题,我希望答案是"它取决于".我只是希望了解更多真实世界的场景和工作流程.

首先,我在谈论同一个项目的不同变化,所以请不要再使用subrepo.

假设您在hg存储库中拥有代码库.您开始处理复杂的新功能A,然后由您的可信测试人员报告复杂的错误B(您有测试人员,对吧？).

如果(修复)B取决于A,那将是微不足道的.你可以ci A然后ci B.

我的问题是当他们独立时(或至少现在看来)该怎么做.

我可以想到以下几种方式:

1. 为B使用单独的克隆
2. 在同一存储库中使用匿名或命名分支或书签.
3. 使用MQ(在A之上使用B补丁).
4. 使用分支MQ(我稍后会解释).
5. 使用多个MQ(自1.6起)

1和2 由@Steve Losh 的优秀博客覆盖,该博客与一个稍微相关的问题相关联.

与其他选择相比,1的一个巨大优势是,当您从处理一件事物到另一件事物时,它不需要任何重建,因为文件是物理上分离且独立的.所以它真的是唯一的选择,例如,A和/或B接触定义三态布尔的头文件,并被数千个C文件包含(不要告诉我你没有看到这样的遗留代码基础).

3可能是最简单的(在设置和开销方面),如果B是一个小的和/或紧急修复,你可以翻转A和B的顺序.但是,如果A和B接触相同的文件,它会变得棘手.如果A和B的变化在同一个文件中是正交的,那么很容易修复无法应用的补丁,但从概念上讲它仍然有点风险.

4可以让你头晕,但它是最强大,最灵活和可扩展的方式.我默认hg qinit使用,-c因为我想标记正在进行中的补丁并推送/拉取它们,但它确实需要一个概念上的飞跃才能意识到你也可以在MQ repo中进行分支.以下是步骤(mq = hg --mq):

1. hg qnew bugA; 为A做出改变;hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; 为B做出改变;hg qref
5. mq branch branchB; hg qci
6. 再次使用A: hg qpop; mq up branchA; hg qpush

采取这么多步骤似乎很疯狂,每当你需要切换工作时,你必须这样做hg qci; hg qpop; mq up <branch>; …

我在一家产品开发公司工作.我们首先做内部发布,然后公开发布.我想知道,其他产品开发公司如何管理他们的发布？你如何给出发行号码？标记源代码管理？

是否有任何所谓的"版本控制系统"也支持实际的版本管理/部署？

我曾经工作的大型机商店有一个自动发布管理工具,它不仅控制对源的并发修改,而且还负责运行编译器,预编译器,数据库绑定实用程序等,使其成为我们的全自动部署工具也是如此.

我的理解是"更现代"的版本控制工具仅支持源管理部分.这种理解是否正确？