摘要

想法与优势

管理员通常直接在他们的实时站点上工作，有时会犯错误，就像所有人一样。结果，实时站点在扩展安装/卸载和重新配置过程中会变得混乱。这个想法是拥有实时站点的副本并进行更改，然后，在经过一些测试后，如果一切正常，您可以批准更改，工具会将它们应用到您的实时站点上。

我还希望将子版本的一些基本功能实现到这个项目中，例如提交/批准、更新/同步、回滚、合并、创建补丁、应用补丁（后续的 SVN 操作）。

使用这个工具，人们将在实时站点上犯更少的错误，并减少紧张感！

里程碑

创建 API 和接口将需要完成这个项目。它们将同时开发，以支持从界面进行测试。我将保留 Joomla! 框架的主要编码思想和标准，希望它将来能成为 Joomla! 1.6 的一部分。

在开发过程中，我将假设实时站点（后续的父站点）和工作副本（后续的子站点）运行在同一版本的 OS/Apache/MySQL/PHP 上，并且服务器配置将保持不变（这个工具只能作为服务器重新配置的测试环境）。

现在我将以一般性的方式描述它将是什么以及它将如何易于使用。以下是一些管理员可以执行的步骤

1. 从主站点创建多个子站点以进行工作（管理员甚至可以创建孙子站点）
2. 修改子站点（重新配置、添加/编辑内容、安装/卸载/更新扩展）并进行测试（如果需要，我们可以在子站点上使用 "间谍机器人" 来轻松确定所做的更改）
3. 通过以下选项之一批准实时站点的更改
   1. 从子站点创建补丁
   2. 将补丁应用到主站点
   3. 直接批准对主站点的更改（实际上它可以先执行 3.1，然后是 3.2，只需一步）
4. 查看在子站点上所做的更改
5. 将子同步到父（当子过时的时候）
6. 将子回滚到父状态
7. 合并两个站点（主-子或子-子）并保持引用完整性

在Joomla!网站上可以进行两种更改，即更改数据库和/或文件系统。因此，API中将有两种类型的函数，它们将分别对数据库和文件系统进行更改。

处理文件系统是最简单的部分，因为每个文件都有最后修改日期，这使得很容易确定哪个文件是更新的。

处理数据库要复杂得多，因为有不同的情况和关系。

我的目标是创建一个API，它不仅会将SVN操作应用到核心表，还会应用到第三方表，这些表可能随第三方扩展而来。

未来增强

也可能为数据库中的每个表创建一个历史表（#__tablename_history），用于在其中保留表行版本。这将实现整个数据库的版本控制。不仅仅是内容，参数、模块位置等也将被版本化。另一件事是创建语言表，并在其中保留表行翻译。

时间线

我计划每天工作8小时，每周工作5天；这是一份全职工作。

4月20日 - 5月17日： 与导师交流的时间
第1周 5月18日 - 22日： 创建从主到子的接口和API函数。（1）
第2周 5月25日 - 29日： 查看子在子站点上所做的更改的接口和API函数。（4）
第3周 6月1日 - 5日： 将子回滚的接口和API函数。（6）
第4周 6月8日 - 12日： 同步子站点的接口和API函数。（5）
第5周 6月15日 - 19日： 创建补丁的接口和API函数。（3.1）
第6周 6月22日 - 26日： 应用补丁的接口和API函数。（3.2、3.3）
第7周 6月29日 - 7月3日： 为中期评估做准备
第8周 7月6日 - 10日： 提交中期评估
第9周 7月13日 - 17日： 合并两个站点的接口和API函数。（7）
第10周 7月20日 - 24日： 预留时间
第11周 7月27日 - 31日： 预留时间
第12周 8月3日 - 7日： 为最终评估做准备，整理所有内容
第13周 8月10日 - 14日： 停止编写代码，总结结果，编写文档
第14周 8月17日 - 21日： 提交最终评估
8月22日 - 25日： 为最后时刻的决定预留时间