Managing contributions

Now I've been thinking about the best way to extend this method to incorporate contributions (eg, modules from the separate drupal.org contributions CVS repository or any other non-drupal-core code). I would welcome comments/suggestions on a good model.

The model I'm currently using:

1. Maintain updated working copies of drupal HEAD and contributions HEAD from drupal.org locally, something like:
   
   [HOST:~/drupal]$ ls -1
contributions
drupal
imports
2. Import drupal into my local CVS repository with vendor/release tags as per method outlined above.
3. Maintain customized versions of drupal using CVS branches which can be diff'd/updated against the latest drupal I've imported into my local CVS repository as suggested at the end of the method above.
4. Make a temporary copy of the complete, updated directory of whatever contribution I want to add to drupal's core in a different and otherwise empty local directory so I can import it to my local CVS repository alone. For example, say I want to include the event module:
   
   [MP:~/drupal/contributions/modules]$ cp -r event ../../imports
[MP:~/drupal/contributions/modules]$ cd ../../imports/
[MP:~/drupal/imports]$ ls -1a
.
..
event
5. Import the contribution with its own vendor/release tags into the proper place in the HEAD branch of drupal I already have in my local CVS repository. In this example, I import the entire event module from the temporary directory that contains the event module directory and only that directory. Note how the event module is imported into the proper directory (ie, "drupal/modules") of the drupal project in my local CVS repository:
   
   [MP:~/drupal/imports]$ cvs import -ko -m "Import module event HEAD on 04 OCT 2004" drupal/modules module_event MODULE_EVENT_20041004
cvs import: Importing /home/mediaped/repos/drupal/modules/event
I drupal/modules/event/CVS
N drupal/modules/event/CHANGELOG
N drupal/modules/event/CREDITS
N drupal/modules/event/INSTALL
N drupal/modules/event/LICENSE
N drupal/modules/event/README
N drupal/modules/event/TODO
N drupal/modules/event/event.css
N drupal/modules/event/event.module
N drupal/modules/event/event.mysql
N drupal/modules/event/event.pgsql
N drupal/modules/event/fields.inc
cvs import: Importing /home/mediaped/repos/drupal/modules/event/po
I drupal/modules/event/po/CVS
N drupal/modules/event/po/event.pot
N drupal/modules/event/po/de.po
N drupal/modules/event/po/es.po
N drupal/modules/event/po/he.po
N drupal/modules/event/po/hu.po
No conflicts created by this import
6. Now the contribution is included in the HEAD of the drupal project in my local CVS repository, so if I update a working copy of that local drupal project (using the update -d option to ensure I get any new contribution directories) or checkout a new HEAD working copy, the newly added contribution will be in that working copy.
7. And, if I would like to add the contribution to one of the branches I have to maintain customized, separate versions of drupal, I just need to update a working copy of that branch with the release tag I established when importing the contribution into my local CVS repository. For example, to get the event module in a working copy of a branch tagged "drupalcustomA":
   
   [MP:~/projects/drupalcustomA]$ cvs -q up -d -j MODULE_EVENT_20041004
U modules/event/CHANGELOG
U modules/event/CREDITS
U modules/event/INSTALL
U modules/event/LICENSE
U modules/event/README
U modules/event/TODO
U modules/event/event.css
U modules/event/event.module
U modules/event/event.mysql
U modules/event/event.pgsql
U modules/event/fields.inc
U modules/event/po/de.po
U modules/event/po/es.po
U modules/event/po/event.pot
U modules/event/po/he.po
U modules/event/po/hu.po

   Note: if you try an update using your new tag and cvs complains that the tag doesn't exist, apparently you have to keep trying different cvs commands using that tag until cvs updates CVSROOT/val-tags. Once you get the tag to work once, it will work from then on. See the section here on error "cvs [checkout aborted]: no such tag".

8. This adds the event module files to that working copy, but I still have to commit them to that branch in my local CVS repository:
   
   [MP:~/projects/drupalcustomA]$ cvs -q ci -m "adding event module"
Checking in modules/event/...
...
done
9. Then I can see that the event module is now a part of that branch by checking the status -v of one of the event module files:
   
   [MP:~/projects/drupalcustomA]$ cvs st -v modules/event/INSTALL
===================================================================
File: INSTALL           Status: Up-to-date

   Working revision:    1.1.2.1 Tue Oct  5 06:46:30 2004
   Repository revision: 1.1.2.1 /repos/drupal/modules/event/INSTALL,v
   Sticky Tag:          drupalcustomA (branch: 1.1.2)
   Sticky Date:         (none)
   Sticky Options:      -ko

   Existing Tags:
        drupalcustomA                            (branch: 1.1.2)
        MODULE_EVENT_20041004           (revision: 1.1.1.1)
        module_event                    (branch: 1.1.1)
10. Later, if there are significant changes to the event module, I'll update it using the same vendor tag, but a different release tag, just as it is demonstrated in the method above for drupal itself. My local drupal head will get the latest event module and I can get it in my customized branches by updating them with the new release tag I make when importing the new event module.
11. I will import every contribution I wish to include in my local CVS repository this way, giving unique vendor/release tags to each. That way I can pick and choose which contributions are included in any of my customized branches of drupal by updating each branch with the release tags of only the contributions I want in that branch.