Hi Try http://coderamblings.com/blog/cvsing-back-your-drupal-site
Sascha On Thu, Apr 1, 2010 at 1:34 PM, Dipen <[email protected]> wrote: > Hi, > 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 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?) > 2> Any tips, experiences, suggestions on the process of removing core hacks > and implementing them outside of core. > 3> Any suggestions on the whole approach? If it can be made more efficient. > I would like opinion of anyone who has dealt with core hacks and removed > them to clear upgrade path. > Thanks > Dipen
