Change control using CVS We're looking to manage our install of Drupal 7 with CVS (sadly Git and SVN are out). Do you have any pointer for things to think about when setting up the repositories? 

Our lay of the land is as follows:


Our staff include UI developers, back-end developers , administrators, and DBAs.
For starting, we're going to install various modules (e.g. Domain, LDAP, Workflow, and Views). We'll write some custom modules down the road. We're also looking for implementing our own look and feel. 
We have Dev, Test/QA, and Production instances of Drupal. The flow of code and configurations  will be from Dev to Test/QA to Production (with some looping between Dev and Test).
We'll have top level domains and several subdomains.
We're on RedHat Enterprise Linux 5.5, MySQL 5.x and Apache 2.x.


What are the ways of managing changes that have worked for you?
Regardless the used VCS, here is what I put in my code repository


A .make file used to download Drupal core, contrib modules and contrib themes and apply patches (if required)
a module folder with only the custom modules
a themes folder with only the custom themes
A build script to

run drush make on the .make file to download Drupal core and contribs to a (VCS ignored) dist folder
copy the modules folder to dist/sites/all/modules/custom
copy the themes folder to to dist/sites/all/themes/custom



This to


properly track changes to the custom code
properly track used core and contribs versions (in the .make file)
prevent core or contribs hack
allow proper patching (Drush Make requires the applied patches to be on publicly accessible)


For the build script, I use Phing but any scripting languages (ant, bash, php, ruby, etc.) could be used. With some additional work, the build script can also be used to run automated test (SimpleTest) and code validation (php -l and Coder Review).

I try to have as much configuration as possible exported into code. Mainly by using exportables through the Features module and by having a project specific profile to define and update non-exportable configurations through its hook_install and hook_update_N implementations. See The Development -> Staging -> Production Workflow Problem in Drupal and the Code driven development: using Features effectively in Drupal 6 and 7 presentation.