将自定义代码mod迁移到开源软件的新主要版本的建议?

时间:2011-05-24 19:07:29

标签: version-control merge smf-forum

我有一个简单机器论坛(SMF 1.1.13)的(脏)生产装置。这是一个干净的安装,一次......大约五年,二十次更新,40 mods前。更不用说直接修补到代码库中的自定义代码了。这开始是一个有趣的副项目,并且在开始时没有任何代码管理实践。

现在SMF 2正在(越来越近)上线,我想升级。但不留下自定义功能。

继续阅读,这是一个常见的软件管理问题,而不是SMF支持问题......

我正在尝试找出将自定义功能移植到新代码分支中的最佳方法。

  • 在某些情况下,自定义1.1.x功能已存在于2.0中。是的,没有为我工作!
  • 在某些情况下,将会有2.0版本的mod软件包,我可以直接在干净的SMF 2版本上安装它们。是的,对我来说工作很少!
  • 在某些情况下,代码端口在两个版本之间相当简单(例如,查询或全局变量构造中的一些小变化)。 (我已经将一些功能/ mods 返回从2.0移植到1.1.x,所以我开始熟悉它。)
  • 在某些情况下,我只需要从头开始重新开发这些功能。

最后两个选项很难管理。

有关如何将大量更改从一个分支移植到另一个分支的任何建议吗? 如果它不是我自己的内部代码,那就是。这是我最初的计划:

  • 干净版1.1.x与我的“脏”生产代码之间的区别
  • 将每行差异映射到一个特征(“代码更新是自定义标记功能,必须逐行移植,并且那里有一个库,我可以安装更新的mod。”)<如果有一个衍生工具生成一个综合报告,而不是一次只能查看几个文件,那么这将是SOMUCHEASIER。 Google和SO搜索没有找到类似的工具 - 有吗?
  • 安装干净的2.0分支
  • 安装可用的更新版本
  • 卷起袖子,按功能浏览我的差异功能(这就是为什么我需要整合的差异报告。这将是一页一页的。)并重新构建它们。

有更好的想法吗? (欢迎发布管理信息的指针,但当然需要注意它实际上不是我的代码所以我的控制权有限。)

否则?我担心我的选择会疏忽自定义功能(不太可行)或留在旧分支上。两个都很糟糕。救命啊!

tl; dr :指向一个diff工具,它将为整个目录执行合并的逐个文件差异报告。和/或帮我找出一种更简单的方法来迁移我的自定义代码。

1 个答案:

答案 0 :(得分:1)

您的计划通常是最实用的方法,但我会说您通过寻找代码级差异来朝着错误的方向前进。由于没有对项目生命周期的版本控制并且没有应用更改的简明记录,因此在检查代码级别的差异时,您正在寻找可能无法提供将相同更改应用于新实现所需的信息的详细程度。

不再考虑代码级别的更改,并考虑应用程序级别的功能和行为更改。您的更改引入了哪些功能?您的应用程序现在以何种方式因您的更改而表现不同?

你说在很长一段时间里都有很多未经修改的变化 - 无论你使用哪种工具,你都将无法找到所有的变化,你仍然需要考虑这个功能和行为改变,以在任何升级的实现中完全代表相同的特征和行为。

您很了解自己的应用程序,使用它,并且即使您可能没有意识到这一点,也很欣赏您所引入的功能更改。

  • 安装vanilla 2.0版本
  • 应用所有适当的模组
  • 应用相关样式
  • 使用新系统,注意行为的差异,并从中发展出一套必要的功能

您的功能集不需要完整 - 在试图找出所有必需的更改的阶段不要停滞,这将花费太长时间。

  • 应用从最近的反馈中收集的功能(最好通过可恢复的模式)
  • 请注意从这一系列必需功能开发时的行为差异
  • 重复