Committing a patch to a contributed module you maintain

One of the most joyous events in open source free software development is when someone contributes code back to code you contributed to the community. Here's what to do when that happens for a module you maintain on Drupal.org.

Following the local development layout described in CVS commands for branching a Drupal 5 module to Drupal 6 (based on add1sun's).

Note: Not all command line output is shown, to better highlight the commands you should enter as the user.

cd /RCS/projects/
ls
mkdir registration_role
export CVSROOT=:pserver:agaric@cvs.drupal.org:/cvs/drupal-contrib
cvs login
cd registration_role/
cvs co -d HEAD_registration_role contributions/modules/registration_role
cvs co -d 5_registration_role -r DRUPAL-5 contributions/modules/registration_role

Head is clearly out of date, just one file in it, and we are developing on the Drupal 5 branch.

cd 5_registration_role/
wget http://drupal.org/files/issues/320087_registration_role.patch
patch -p0 < 320087_registration_role.patch

patching file registration_role.module

cvs commit -m "fix to work with Ubercart, patch supplied by abhaga and christefano in issue http://drupal.org/node/320087"

cvs commit: Examining .
? 320087_registration_role.patch
/cvs/drupal-contrib/contributions/modules/registration_role/registration_role.module,v <-- registration_role.module
new revision: 1.2.2.3; previous revision: 1.2.2.2
cvs commit: Using deprecated info format strings. Convert your scripts to use
the new argument format and remove '1's from your info file format strings.

Note how it skips over the patch file. And complains about Drupal's format strings, wah wah. Face it, CVS, you're deprecated, so no one cares about your precious format strings.

For testing a patch that's not for a module you maintain, see Applying a patch to Drupal CVS checkout.

Resolution