[development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.
gerhard at killesreiter.de
Thu Apr 1 12:58:32 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
> I have started working on a large code base built using drupal 5.2
> and now there is a requirement to upgrade it to 5.22 and eventually
> 6. The problem is that lot of core files (modules, include folder)
> was hacked over a period of last 1 year to make drupal work
> according to req, and things were obviously not done drupal way. I
> am working on identifying changes that were made to core and then
> would attempt on implementing those changes from a custom module,
> reverting the core to 5.2 clean state. The job would have been
> easier if source control management was used from start in the
> project, but that did not happen and hacks were made before SCM
> started recording them and hence I can not rely on svn history. What
That sounds like really fun project to take over...
> I am doing right now is the following:
> 1> I have downloaded drupal 5.2 for reference.
> 2> Have trunk of tainted project checked out.
> 3> Diffing module files one by one ( against 5.2 download in step 1, so
> diffing hacked node.module against 5.2 node.module) and recording changes to
> find out what changes were intended when the developer hacked the core (eg.
> node module file)
> For 3 to happen, I can write a script to get diff of all files in say
> includes folder, but that would give me just the diff file and it would be
> hard to study why were the changes done. But I am sure I can use it as a
> starting tool to find out which files have changed in core when measured
> against cleand drupal 5.2 and then focus on those files.
> I wanted suggestions and tips on:
> 1> Apart from svn history, diffing files one by one, does any one have
> suggestions to find out changes between hacked and clean file? Maybe at a
> folder level? Like diff the whole include folder or diff the whole modules
> folder. (I know about beyond compare, anything else?)
diff has a "recursive" option which allows you to look at whole
directories. Emacs has a nice diff mode to use this to compare
directories in a convenient way.
You should also check the other folders that Drupal has, not only /modules.
> 2> Any tips, experiences, suggestions on the process of removing core hacks
> and implementing them outside of core.
You should try to identify changes and group them into the feature
they were trying to achieve. Then ask the client if said feature is
still required. Then move to contrib theme/module.
> 3> Any suggestions on the whole approach? If it can be made more efficient.
Find the person who did all the hacks and whack said person on the
head using a big cluestick. Will not help with the project, but might
be very satisfying.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the development