The first link that shows up in my autocomplete browser history when I type “dr” is http://drupal.org/node/321. There is a very simple explanation for this. This is the node I refer to when I need the CVS checkout command (the “download” command in CVS speak), that allows me to obtain a particular version of a Drupal contributed project (i.e. a theme or module). This is the line that I look for on that page:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-5--1-0 -d moduleName contributions/modules/moduleName
Why use CVS instead of getting the tar ball directly from the project page? Two words: easy maintenance. Here's a little recipe that will make your life easier...
Footwork
First off, identify which release of the module you want/need to get and figure out the corresponding tag (the “release” or “version” in CVS speak) syntax. Identifying which release to use may require a bit of reading but generally you will want to go for the latest.
As for determining what tag the chosen release has, there are at least two avenues:
You may go to the module page and figure out the corresponding revision tag based on the particular release. Let's use the "views" module as an example. If I want to checkout the 5.x-1.6 release, I may be able to figure out that the CVS tag is DRUPAL-5--1-0. But what about, say, release 6.x-2.0-rc3?
This is where the second avenue may come in handy: Drupal's browsable CVS repository (http://cvs.drupal.org/). If I navigate to http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/views/, I will be able to see the different releases available for this module by looking under the “Sticky Tag” drop down menu (see below). It now becomes much easier now to find out that the tag name for release 6.x-2.0-rc3 is DRUPAL-6--2-0-RC3.
Now that I have this basic information, I can checkout the the module to my development machine.
$ cd /var/www/mysite/sites/all/modules $ cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--2-0-RC3 -d views contributions/modules/views
Fancy Pants
Now, if you want to work in a smart way, versioning your own code is a good place to start. I personally use subversion (svn), but there are several other options out there (http://en.wikipedia.org/wiki/Revision_control). The question here is: how do you combine and take advantage of CVS (Drupal's code) and svn (your code)?
Once you have checked out the module using CVS as we did above, simply add and commit (the “upload” in svn speak) the new code to your svn repository:
$ cd /var/www/mysite/sites/all/modules $ svn add views $ svn commit views -m”initial commit of views release 6.x-2.0-rc3”
The new module is now part of your repository and may be checkedout onto your server!
Hat Trick
So what's really cool about this process from a maintenance perspective is that next time a new release of a module comes out, you can simply update the module code rather than having to download/un-tar/overwrite. And if you use svn, your benefits will be even greater.
Let's look at what would need to be done if a rc4 release of "views" became available and I wanted to deploy the code both locally and to a remote sever:
On my development machine (local)
$ cd /var/www/mysite/sites/all/modules/views $ cvs update -dP -r DRUPAL-6--2-0-RC4 $ svn ci -m”update views to release 6.x-2.0-rc3”
And on the remote machine:
$ cd /var/www/mysite/sites/all/modules/views $ svn up
You'll be done before the coffee is even ready! Bookmark node 321 and this page!
