[development] Local repository best practices

[David Cohen]

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 at 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.
>