[development] Local repository best practices

[David Metzler]

I doubt you'll find consensus, but good luck on trying ;).

I'm writing this from the perspective of a client.  I don't develop  
modules for other people, but just for use in house.  Here's what I  
do, but I confess to not using svn for version management of modules  
we don't develop.   Rather we rely on release module and the  
drupal.org infrastructure for releases we don't care about but rather  
only use svn for the code that's specific to us.    Some of the folks  
at our college are trying out using SVN to manage drupal deployment,  
they often complain that it's more trouble than its worth.

  I organize my SVN tree around deployable units, and for me that's  
designed and organized around the test plan.  That makes it easier to  
understand what's been tested and ready for deployment.

themes/trunk - all the themes for my site
custom_module_a/trunk  The version tree for that module

Projects that have database changes have a db_api directory within  
them, so that we can tag/branch accordingly. Here's some real  
examples of project paths.  In the example ilc refers to a large  
project that handles independent learning contracts at my college.

projects/themes/trunk/evergreen_app
projects/ilc/trunk/db_api
projects/ilc/trunk/modules/myilc
projects/ilc/trunk/xsl
projects/ilc/1.0/db_api
projects/ilc/1.0/modules/myilc
et.c.


I then write svn export scripts to deploy the bundles to test and  
production sites.  This leaves me free to deploy verson_1 of  
module_x  or version 2 of module_y, and have separate test plans/ 
release dates for each of these.  Doing this cuts down on the work of  
creating a bunch of branches every time I have a separate development  
track going on.  I tag within the themes trunk at major theme rev  
changes.

I explain this only to suggest that best practices should really be  
built around your sites test and deployment strategies.  For small  
organizations with small number of projects, this might be properly  
organized around the site, but as you grow, (we use drupal for our  
school's portal) there's a lot of need to design svn repositiories  
around the project rather than the site.   We do use tags branches  
and trunks as you've indicated.

This may n ot be what you're asking and if not, I apologize.  ;)

Dave
On Sep 9, 2008, at 1:15 PM, Angela Byron wrote:

> I've been doing some research for a client on best practices  
> surrounding repository management, and wanted to take this  
> discussion to the developer list and see if we could get some  
> general consensus, and document it as a best practice in the  
> handbooks.
>
> I found a bunch of discussion on this topic:
> * http://drupal.org/node/118936
> * http://www.workhabit.com/labs/svn-repository-structure-drupal- 
> projects
> * http://ceardach.com/blog/2008/06/development-environment-drupal
> * http://pingv.com/blog/cyberswat/200706/project-management-drupal
> * http://www.svntalk.com/node/6
> * http://agaricdesign.com/agarics-svn-repository-structure-for-site- 
> maintenance-and-web-development
> * https://svn.bryght.com/dev/browser
> * http://www.advantagelabs.com/advantage_labs_svn_repository_structure
> * http://www.codegobbler.com/svn-repository-structure-drupal-projects
>
> Most of these discussions are around Drupal *shops* who setup SVN  
> to manage the development of their clients' sites, or who host  
> their clients' Drupal sites and manage updates via SVN.
>
> 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.
>
> We typically do something like this:
>
> /branches:
>   This is where "crazy" development happens that will break other  
> stuff.
> - /drupal-6-port
> - /crazy-new-feature
>
> /tags:
>   This is where deployments go. Whenever we move a deployment to prod,
>   we tag it first so that we can see a historical record of things  
> that
>   were put 'live'
> - /2008-09-03-description-of-deployment
> - /2008-09-08-description-of-deployment
>
> /trunk:
>   The latest development code in preparation of deployment.
>   Should be kept stable at all times. Minor fixes can go in here, but
>   major ones (particularly porting tasks) get a dedicated branch.
>
> Beneath each directory above is something like this:
>
> - /www:    Drupal files, modules, etc.
> - /assets: Things like wireframes, TinyMCE .zip files, and anything  
> else
>            that shouldn't be web acessible.
> - /db:     Database backup files
>
> What are other people doing for this use case?
>
> -Angie