我已经在大型商业应用程序中尝试了这两种方法。

哪种方法更好的答案在很大程度上取决于您的具体情况，但我会写下我迄今为止的整体经验。

总体上更好的方法（根据我的经验）：主干应该始终保持稳定。

以下是此方法的一些指导原则和好处：

• 在其自己的分支中对每个任务（或相关的任务集）进行编码，然后您将可以灵活地选择何时合并这些任务并执行发布。
• 在合并到主干之前，应该对每个分支进行 QA。
• 通过对每个单独的分支进行 QA，您将更容易准确地了解导致错误的原因。
• 该解决方案适用于任意数量的开发人员。
• 此方法有效，因为分支在 SVN 中几乎是即时操作。
• 标记您执行的每个版本。
• 您可以开发暂时不打算发布的功能，并准确决定何时合并它们。
• 对于您所做的所有工作，您都可以从提交代码中受益。如果你只在主干之外工作，你可能会经常保持你的代码未提交，因此不受保护并且没有自动历史记录。

如果您尝试做相反的事情并在主干中进行所有开发，您将遇到以下问题：

• 日常构建的持续构建问题
• 当开发人员为项目中的所有其他人提交问题时，生产力损失
• 更长的发布周期，因为你需要最终得到一个稳定的版本
• 不太稳定的版本

如果您尝试保持分支稳定并将主干作为开发沙箱，您将根本无法获得所需的灵活性。原因是您无法从主干中挑选要放入该稳定版本的内容。它已经在后备箱中混合在一起了。

我会说在主干中进行所有开发的一种特别情况是，当您开始一个新项目时。根据您的情况，可能还有其他情况。

顺便说一句，分布式版本控制系统提供了更多的灵活性，我强烈建议切换到 hg 或 git。