当前位置：文江博客话题详情

使用现有的各种 VCS（版本控制系统）来跟踪 Drupal 项目有哪些优点？

发布于 2024-08-21 14:26:24 字数 331 浏览 4 评论 0原文

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

SVN
Bazaar (bzr)
Git
Mercurial (hg)

我知道它们之间的一般比较，但想了解它们对于 Drupal 的优点/缺点。如果您正在（或已经使用）Drupal 中的任何一个：

您的设置是什么？
您选择的 VCS 是否适合管理 Drupal 项目？
什么不可以？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦在深巷 2024-08-28 14:26:24

另一个颠覆设置在这里。

基本设置是：

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

优点：

主要是，非常完整地概述了我们任何项目中任何代码所发生的所有事情:)
特别是，能够跟踪和重用不同项目中不同版本的核心或贡献模块，即使进行任意自定义更改，也不会造成难以管理的混乱（我们何时、为什么以及在何处在 pathauto 中使用了这一自定义单行修复，以及何时、为何以及何处停止使用它 - SVN 日志将回答这个问题）可
重复部署 - 如果生产服务器上出现任何问题，我们可以导出那里使用了一套精确的代码，所有一次性修复、调整和“特殊功能”都在现场（显然只有与正确的数据库备份结合使用才有用；）

缺点：

从描述中很容易看出如上所述，这种设置在导入新的核心/模块版本时会产生一些管理开销（大多数时候它甚至看起来没有必要，因为应用特殊修复是一件很少见的事情）
广泛使用外部定义，这样使得更新操作本地签出有点长
当变更集意味着对项目本身和通过外部导入的自定义模块进行更改的组合时，它不会是原子提交，因为它们必须单独签入！

结论：

只要您只需要管理少数项目/站点，这可能不会有效，并且您可能会更好地提交和维护整个设置（核心、贡献和自定义内容）合并在一个分支内。

但我可以保证，一旦您必须并行管理 10++ 个项目（一些在 5.x 上，一些在 6.x 上，所有项目都处于不同的更新和/或自定义级别，通常重用相同的自定义），能够分辨到底在哪里使用什么代码是一个巨大的缓解！

PS：重读我的讲道，很明显它并没有真正解决你关于不同 VCS 相对优点的问题 - 对此感到抱歉，但也许它无论如何都有帮助；）

Another subversion setup here.

Basic setup is:

We track Drupal core and all contributed modules/themes we use each within their own folder in one part of our repository
- Each of those has one subfolder 'drop', where new versions are copied into, once we start to use them.
- Then we commit this as 'dropped version 6.x-y' - this leads to a local history of the release versions of Drupal core or the module in question (redundant to the 'official' cvs history at drupal.org, but more convenient to search/diff in case of problems)
- Then we create a branch for the drop, named after the version (e.g. drupal-6.15, views-6.x-2.8) - this will normally be just used as is (see 'externals' below), but also serves as the baseline for custom changes to the module, if we need them. We try to avoid changes to core or contributed modules, but sometimes we need to fix a bug and can not wait untill the fix eventually ends up in an official release. So we make our changes and commit them on that branch. Once a new version comes in, we can diff it against our branch and eventually reapply the fix to the new versions branch, if it does not incorporate the fix already. This way, we have a complete and reusable overview of all core and module versions we use in different projects, including any customizations we eventually needed.
For each of our Projects (sites), we create the usual SVN trunk/branches/tags hierarchy in a different part of the repository
- We then use Subversions 'externals' definitions to pull in the core version, as well as all the additional modules we need from the branches described above. The important part here is that we can pull any version we need, so some sites might use a specially patched version of module x, while others might pull an unpatched previous version, and yet another uses the latest and greatest official release - we don't have to keep track of this mess, as SVN can tell us exactly what gets used when and where, at all times!
- Then we add our project/site specific stuff - settings file(s), .htaccess files, project specific modules/themes, etc.
- New development happens on trunk
- Once we reach a release point, we create a release branch and tag that
- We export that tag to the test/staging/live servers as needed
- Meanwhile, new development can continue on trunk
- Should we need to apply a fix to the current release version, this happens on the release branch
- Again, the fix gets commited, tagged and finally exported and deployed
- Should the fix be something needed in general, it gets merged back onto the trunk, so that it will be available in future versions in general
- Lather, rinse, repeat ...

Pros:

Mainly, a quite complete overview of all things that ever happened to any code within any of our projects :)
Especially, the ability to track and reuse different versions of core or contributed modules within different projects, even with arbitrary custom changes, without creating an unmanageable mess (When, why and where did we use this custom one line fix within pathauto, and when, why and where did we stop using it - SVN logs will answer that)
Reproducible deployments - should anything go wrong on a production server, we can export the exact set of code used there, with all one time fixes, adjustments and 'specialties' on the spot (obviously only useful in conjunction with proper database backups ;)

Cons:

As easily to be seen from the descriptions above, this setup creates a bit of an administrative overhead when importing new core/module versions (and most of the time it even seems needless, as applying special fixes is a rare thing to do)
Using externals definitions extensively like that makes update operations to the local checkout a bit more lengthy
When a changeset implies a combination of changes to both, the project itself and a custom module imported via externals, it will not be an atomic commit, as they have to be checked in separately!

Conclusion:

As long as you have to manage only a handful of projects/sites, this might not be effective, and you might be better of committing and maintaining the whole setup (core, contrib and custom stuff) combined within one branch.

But I can assure that once you have to manage 10++ projects in parallel (some on 5.x, some on 6.x, all at different update and/or customization levels, often reusing the same customizations), being able to tell what code gets used where exactly is a huge relieve!

PS: Rereading my sermon, it is somewhat obvious that it does not really address your question regarding the merits of different VCS as compared to each other - sorry for that, but maybe it helps anyway ;)

回复收藏 0 原文

猥琐帝 2024-08-28 14:26:24

我们的设置基于 Subversion。我们只有很少的人（少于 4 人）可以对网站进行更改，我们考虑过像 Git 这样的 DVCS，但得出的结论是它太过分了。

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

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

相反，您应该从sites/all/modules 目录中删除该模块，然后删除svn export 以获得最新代码的干净版本。

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

部署模块是另一件需要考虑的事情，具体取决于您的工作流程。

回复收藏 0 原文

a√萤火虫的光℡ 2024-08-28 14:26:24

自从我提出这个问题以来，Drupal 方面出现了相当令人惊讶的发展：他们有有点可能选择 CVS 的替代品！考虑到大规模的社区支持以及对分布式 VCS 的需求，他们可能会转向 git。

由于文档和跨平台支持较差（与 Bazaar 和 Mercurial 相比），我之前曾考虑并放弃 git，但从那时起，它们在这两个领域都取得了巨大的进步，无论您的情况如何，它现在似乎都是一个非常好的选择。

因此，如果您正在考虑为“核心”或 contrib 模块做出贡献，或者为社区编写自己的模块，我强烈建议使用 git，因为它将在 Drupal 社区中获得最多的支持和用户。因此，即使您只是跟踪自己的网站，它也可能是一个不错的选择。

回复收藏 0 原文

路还长，别太狂 2024-08-28 14:26:24

与任何其他通用软件源相比，Drupal 没有任何特定要求。

下面是 Git/Mercurial 与 Subversion 的对比：

Git（对于 Mercurial 也是如此）
- 行结尾将被标准化（无论 RL+LF 或 LF 或者...它都会被存储为“行返回”并按照操作系统格式所述进行解包）
- 单个文件 .gitignore 可以告诉您要忽略的所有文件
- 您的每个文件夹中不会有 .svn 文件夹（这会强制使用慢速导出功能或自定义批处理来删除它们）
- 本地设置极其简单
  1. 下载 Git 并启动命令行
  2. 转到您的项目文件夹
  3. git add . && git commit -m“我的第一次提交”
  4. 完成，您现在可以更改文件并恢复到您的第一次提交
- 很高兴通过 GitHub 共享开源项目中的代码
- 如果您想要一个简单的 GUI（需要一些高级功能），可以在 Windows 上安装 TortoiseGit功能），但安装比 TortoiseSVN
在 Windows 上有 TortoiseGit一个简单的 GUI（以一些高级功能为代价），但它比 TortoiseSVN Subversion (SVN)
- 创建您自己的私人服务器更加简单
- 如果您想要一个简单的 GUI（需要一些高级功能），可以在 Windows 上安装 ToirtoiseSVN李>
- 明确的客户端/服务器：这意味着您还必须保持服务器运行（可能与客户端在同一台计算机上）才能使用客户端
我不能对Bazaar说太多因为我还没有使用过它，

显然我偏向于 Git 和 Mercurial。两者都是较新的。我个人更喜欢 Git，因为：

它不需要 Python
有便携式版本
它允许我重写历史

不过你应该注意到 Mercurial em> 最近引起了 Google 的关注（对于 Google 代码），并且学习起来比较简单。您可以从 http://progit.org/book/ 学习 Git (前三章应该足够了）。

至于项目文件夹结构，我建议你查找其他答案。记住您的目标（例如：测试、在各种机器上快速部署...），并备份您的存储库。这意味着将项目文件夹复制到 Git/Mercurial 的远程位置，并复制 Subversion 服务器存储库以实现 Subversion。除此之外，所有这些都具有允许您在提交之前运行测试的钩子，并且它们具有错误跟踪系统的接口。

最重要但并非最不重要的一点是，如果您在项目中在版本控制下使用其他库，请考虑这一点！ Git 和 Mercurial 允许跟踪 Subversion 存储库（通过 git-svn），而不是相反。 Mercurial 还可以跟踪Git 存储库，而不是相反（还）。跟踪远程存储库允许您获取最新版本以及您将使用的远程源代码的更改日志。它还允许您修改它。

Drupal doesn't have any specific requirement compared to any other general software source.

Here is Git/Mercurial vs. Subversion:

Git (but also true for Mercurial)
- Line endings would be normalized (no matter RL+LF or LF or... it would be stored as a 'line return' and unpacked as the OS format says)
- A single file .gitignore allows to tell all files you'd like to ignore
- You wont have a .svn folder in each of your folders (which forces to use the slow export function or a custom batch to remove them)
- Extremely simple to setup locally
  1. Download Git and start the command line
  2. Go to your project folder
  3. git add . && git commit -m "My first commit"
  4. Done, you now can change files and revert to your first commit already
- Good to share code in an OpenSource project via GitHub
- Has TortoiseGit on Windows if you want a simple GUI (at the cost some advanced features), but it's a bit harder to install than TortoiseSVN
Subversion (SVN)
- Somewhat simpler to create your own private server
- Has ToirtoiseSVN on Windows if you want a simple GUI (at the cost some advanced features)
- Clear client/server: Meaning also you'll have to keep a server running (possibly on the same machine as the client) to use the client
I cannot say much about Bazaar as I haven't used it

Clearly I'm biased toward Git and Mercurial. Both are more recent. I personally prefer Git because:

It doesn't require Python
There is portable version
It allows me to rewrite history

Still you should note that Mercurial got Google's attention recently (for Google Code) and it's somewhat simpler to learn. You can learn Git from http://progit.org/book/ (the first 3 chapters should be enough).

As for the project folder structure, I suggest you look-up other answers. Keep in mind your goal (ex: testing, quick deployment on various machines...), and backup your repository. That means copying your project folder to a remote location for Git/Mercurial, and copying your Subversion server repository for Subversion. Outside of that, all have hooks allowing you to run tests before committing, and they have interfaces to bug tracking systems.

Least but not least, if you use other libraries under version control in your project, consider that! Git and Mercurial allow to track a Subversion repository (via git-svn), not the opposite. Mercurial can also track a Git repository, not the opposite (yet). Tracking a remote repository allows your to get the latest version with a change log of remote source code you'll be using. It also allows you to modify it.