Oct
30
2006
I was recently working on an older Drupal site that hadn't been updated in a while. It used lots of contributed modules and we were unsure whether these had any custom hacks in them. So, I needed a way to find what version of the module was in use, and then pulling down to relevant version of that module in a format suitable to use in a "diff" tool.
So, I did a couple fancy little things and wanted to share them for others to enjoy:
Finding the Id string
Many Drupal modules have an "Id" string in the top of the file. The CVS system replaces these with some information about the file when they are checked out of CVS. This gives you an automatically updated set of information about the file you are using. So, if we can find files named .module, grab the first 3 lines of those files, search for the string Id, and output the results into a file then we've tackled the question "What version of this module do I have?
find ./ -name '*.module' -exec head -n 3 {} \; | grep Id >> versionNumbers.txt(Note that all of the pieces of text that are in these little boxes should be one one line.)
Which gives you output like:
// $Id: devel.module,v 1.108 2006/10/15 21:59:25 weitzman Exp $
// $Id: devel_node_access.module,v 1.7 2006/08/17 12:33:29 dww Exp $
// $Id: color.module,v 1.3 2006/10/29 15:13:01 unconed Exp $
// $Id: gsitemap.module, v4.8.11Getting the corresponding code from CVS
The next step is to use that Id information to find the version from CVS. Fortunately, CVS provides the capability of checking out files based upon a date. First, we need to parse out the section of the Id string that contains the module name and the date. The fanciest way would be to use awk, but the problem with that is not all modules use the Id string. So, I used the OpenOffice.org Calc spreadsheet program and the Text to Columns Macro. From there, two formulas got me the data I wanted:
=LEFT(C1;FIND(".";C1)-1)and
=CONCATENATE("cvs -d :pserver:greggles@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-4-6 -D """;F1;""" contributions/modules/";B1)The benefit of doing this in a spreadsheet is that it makes it easy to find modules (e.g. gsitemap) where the Id string has been implemented in a non-standard way so that I can search down the right details myself.
When the information is present, these functions get me the module name out of name.module and then provides a cvs checkout command to pull down the DRUPAL-4-6 branch from the date that was in the top of the module file.
So, I paste those into my shell pastebuffer, they pull down all the modules, and I can do my diff.
What's the Diff
Once you are there it's trivial to use your favorite comparison/diff tool to find the difference between the modules. And from there, you can follow the road back to Drupal sanity by removing custom modifications from the modules and implementing them as theme_ and hook_ functions.
Whew! That was difficult, but now it's easier for others to do (or for me to do again, I have a feeling I'll need it).
Drupal Project Module Updates
It's worth noting that most of this tom-foolery will no longer be necessary after some more improvements to the Drupal Project Module. If you are interested in supporting that work, take a look at this overview and fundraising page.
Final note: there are many ways to do these kinds of tricks, these just happen to be the way.
Bookmark/Search this post with:
Comments
Khalid writes:
Hey Greg
Your grep works only if the Id is in the first 3 lines. There are cases where someone has some comments and stuff before the actual $Id$ string.
Here is a better grep that will catch them anywhere:
find ./ -name '*.module' -exec grep "\$Id" {} \; >> versionNumbers.txt
Greg writes:
Thanks for the idea, Khalid.
With shell commands there are many ways to skin the cat - your grep has the benefit of working when the $Id tag is beyond the first three lines, but has the drawback of potentially matching a variable later in the file named $Id. We don't use varialbes like that in Drupal very often, but it could happen.
In my use I found that they were all within the first 3 lines. It's a trade-off of what works for a specific situation, but your modification is definitely a good alternative for people to keep in mind.