Version control 使用现有的各种VCS（版本控制系统）跟踪Drupal项目的优点是什么？

我正试图为我的Drupal工作流程找到最好的版本控制策略。我每次安装都有多个站点，我很确定每个站点都有一个单独的存储库。据我所知，值得考虑的VCS有：

• SVN
• 集市（bzr）
• 吉特
• 汞（汞）

我知道它们通常是如何相互比较的，但我想为Drupal了解它们的优缺点。如果您正在（或已经）为Drupal使用以下任何一项：

• 你的设置是什么
• 您选择的风投在管理Drupal项目方面效果如何
• 什么不可以

---

我们的设置基于Subversion。我们有一小部分（少于4）的人可以对站点进行更改，我们考虑过像Git这样的DVC，但得出结论认为这是过度使用

在提交任何更改之前，我们使用测试模块，如果添加了未涵盖的功能，我们将进行新的测试。在我看来，在您提交更改之前的测试步骤远比您最终决定使用哪个版本控制程序重要

在处理这些程序时，您应该记住的另一件重要事情是，您不应该只是定期签出以更新生产站点上的代码。这将隐藏.svn或其他可能包含密码和其他敏感数据的目录

相反，您应该从sites/all/modules目录中删除模块，然后进行

svn导出

，以获得最新代码的干净版本

版本控制是管理站点的系统的一部分，请确保通过定期备份数据库本身（最好与svn提交同步）以及将CCK内容类型的定义存储在主站点外部（如果可以），来跟踪存储在数据库中的站点配置。您可以导入和导出内容类型和视图，以便在需要重建站点配置时它们不会卡在数据库中

---

根据您的工作流程，该模块是另一个需要考虑的问题。

这里的另一个颠覆设置。

基本设置为：

• 我们跟踪Drupal核心以及我们在存储库的一部分中各自使用的所有贡献模块/主题
  • 每个文件夹都有一个子文件夹“drop”，一旦我们开始使用新版本，就会将其复制到其中
  • 然后我们将其提交为“Drupal version 6.x-y”-这将导致Drupal core或相关模块的发布版本的本地历史记录（Drupal.org上的“官方”cvs历史记录是多余的，但在出现问题时更方便搜索/diff）
  • 然后，我们为drop创建一个以版本命名的分支（例如drupal-6.15，views-6.x-2.8）-这通常会按原样使用（请参见下面的“externals”），但如果需要，还可以作为对模块进行自定义更改的基线。我们试图避免对核心模块或贡献模块进行更改，但有时我们需要修复一个bug，不能等到修复最终在正式版本中结束。因此，我们进行更改并在该分支上提交它们。一旦有了新版本，我们可以将其与我们的分支进行区分，并最终将修复程序重新应用到新版本分支，如果它还没有包含修复程序的话。通过这种方式，我们对我们在不同项目中使用的所有核心和模块版本都有一个完整的、可重用的概述，包括我们最终需要的任何定制
• 对于我们的每个项目（站点），我们在存储库的不同部分中创建通常的SVN主干/分支/标记层次结构
  • 然后，我们使用Subversions定义从上述分支中引入核心版本以及我们需要的所有附加模块。这里重要的一点是，我们可以拉取我们需要的任何版本，因此一些站点可能会使用经过特别修补的模块x版本，而其他站点可能会拉取未修补的早期版本，而另一个则使用最新和最好的官方版本-我们不必跟踪这种混乱，因为SVN可以准确地告诉我们何时何地使用了什么，任何时候
  • 然后我们添加项目/站点特定的内容-设置文件、.htaccess文件、项目特定的模块/主题等
  • 树干上出现了新的发展
  • 一旦我们到达一个发布点，我们就创建一个发布分支并标记它
  • 我们根据需要将该标记导出到测试/登台/实时服务器
  • 同时，新的发展可以在主干上继续
  • 如果我们需要对当前发布版本应用修复程序，则在发布分支上会发生这种情况
  • 同样，修复程序会提交、标记并最终导出和部署
  • 如果修复程序通常是需要的，它会被合并回主干上，以便在将来的版本中普遍可用
  • 泡沫，冲洗，重复

优点：

• 主要是对我们任何项目中的任何代码所发生的所有事情的完整概述：）
• 特别是，能够在不同的项目中跟踪和重用不同版本的核心或贡献模块，即使有任意自定义更改，也不会造成无法管理的混乱（我们在pathauto中何时、为何和何处使用此自定义单行修复程序，以及何时、为何和何处停止使用它-SVN日志将回答此问题）
• 可复制的部署—如果生产服务器出现任何问题，我们可以导出该服务器上使用的确切代码集，以及现场的所有一次性修复、调整和“特殊性”（显然，只有与适当的数据库备份结合使用时才有用；）

缺点：

• 从上面的描述可以很容易地看出，这种设置在导入新的核心/模块时会产生一些管理开销