Webchick, When I hand over source code to a client, I tell them to treat it like a vendor branch (as documented in the subversion manual). Then, they might customize if further for themselves. But most of my clients would ask me to make changes. I would give them updated files, they'd run the update.php script and be good to go. I've considered documenting my own source code repository, as I've put a lot of thought into it. But have not had time to write it up. I use subversion, and arrange it like this: drupal/5/ contains everything for drupal-5 based sites (drupal/6/ for 6.x and so on) drupal/5/vendor/ contains unmodified drupal core. For example drupal/5/vendor/5.6 contains Drupal-5.6. drupal/5/custom contains drupal with my patches. Yes, from time to time drupal must be patched. For example, drupal/5/custom/5.6 is modified Drupal-5.6 drupal/5/modules contains all the modules I use in all my sites. Sometimes modules need patching, too. I don't bother to keep a vendor branch of each one. I just keep the version I prefer. Usually I've checked a particular version of the module out of drupal cvs. Sometimes I keep multiple versions of a module around, for example drupal/5/modules/location is the latest location module while drupal/5/modules/location-1.x is an older version. I also have directories drupal/5/themes and drupal/5/profiles. drupal/5/sites contains the "sites/all" directory of the sites I'm working on. For example, drupal/5/sites/orphanage/modules contains modules used by theorphanage.com, while drupal/5/sites/drupalforfacebook/modules contains modules used by drupalforfacebook.org. These directories do not actually "contain" modules. Instead, I use svn:externals to refer to modules in drupal/5/modules/. By using svn:externals, I can patch one of my modules for one site, check in the change, then all my sites get the fix when I update them. This approach may not work for everyone, but it works for me. drupal/5/work contains the root of each project I'm working on. Again, I use svn:externals here. Each work directory contains htdocs/ (an svn:externals link to drupal/5/custom/X.y), and also svn:externals to the drupal/5/sites/something. (I use some well-placed symbolic links to keep the site-specific code completely separate from Drupal core). The work directory also contains documentation and other files specific to a particular site, which are not part of the website itself. So the key feature of my approach is the use of the svn:externals property. Using this, I can change a module (or version of core) for one site, and easily propagate the change to other sites. Another recommendation of mine is to not make the drupal root directory the root of the project. Instead, put drupal in a directory (I call it htdocs/) and keep documentation (or comps, or anything not part of the site) in source control, but not separate from the website files. I think this is a great question and look forward to reading other responses. -Dave On Tue, 09 Sep 2008 16:15:17 -0400, "Angela Byron" <drupal-devel@webchick.net> said:
However, I'm curious what people generally use in terms of repository structure/deployment strategy *after* development is complete, and they hand the site over to the client so that they can be self-sustaining? It doesn't really seem like they need a vendor branch with various versions of Drupal and contributed modules. The repository is around just their own site.