One of our clients asked us how to structure their SVN repository, and it occurred to me that I haven't read anything about this online for Drupal-based projects, so I thought I'd blog it and see if we can get a dialogue going on best practices for larger projects.
This is by no means complete, but it shows the general structure we start with on projects. The larger he project, the more teams you have working simultaneously, and the more parallel development efforts you have, the more complex your svn administration can get.
I know some distributed teams that use SVK in lieu of Subversion proper (it's easy to install: 'apt-get install svk'). BestPractical, best known for their Request Tracker project, acquired and maintains the project.
We usually structure our svn repo as follows:
trunk/
htdocs/
sites/all/themes/
mytheme/
sites/all/modules/
contrib/
custom/
sql/
scripts/
assets/
Ideally, we avoid a lot of SVN administration with this model - we've learned that a lot of branching and tagging can end up meaning we need to distract developers or get a build manager, so we generally end up using the most simplistic model we can. Advantage published an article similar to this one, and obviously you'd need to carefully consider this structure for things like multi-site.
What are the other approaches larger projects use?
jonathan's blog
Comments
close to our setup
close to our setup :)
trunk/
--www/
--modules/ (contrib and symlinked in sites/all)
--sitename.whatever/ (working directory and symlinked in sites/)
--scripts/
--files/ (keep the files behind www/)
--patches/
--settings.php
(input filter wont let me use a pre tag)
The settings.php is only there as an example and intended to be copied from trunk/ and placed in sitename.whatever/ so this way you never have to worry about possibly committing changes to the settings.php like the database info.
Pretty close. We use a
Pretty close.
We use a settings.php.prototype file, which contains our basic developer database connection (but not staging or production). This allows developers to get ramped up on a new project quickly.
I've heard of developers going both ways on committing the 'files' directory. My take: commit files when you have to, and only those that your app is dependent on.
oh forgot.. files dir isn't
oh forgot.. files dir isn't actually in svn. we use rsync to deal with that since you can get some huge video files sometimes and thats just a pain to keep in svn.
One more abstraction
I always use one more layer of abstraction. Often there is more to a project than just code. Often there are things like assets in the form a copy deck, source images (unscaled), documentation etc.
My structure usually looks something like this:
trunk
source
etc...
deploy
etc...
All files that are not meant for deployment but still part of the project and need to be version controlled are stored in source. Besides the for mentioned items this can also be Flash source (fla's) and other kinds of source code that compiles into binaries.
Yours are very similar..
Yours are very similar.. That's what we drop into our "assets" dir.
If I expand that out from the last project I worked on, we have:
assets
--comps
----project.psd
--docs
----Project_Technical_Spec_v1.pdf
----Release_Plan_v6.pdf
--sources
----flashapp_v1 (both src and build dirs)
----flashapp_v2 (both src and build dirs)
So yeah, fairly on the mark in your assessment of that.
our repo
Our repo is like this:
trunk
--projects
----clientname1_projectname1
----clientname1_projectname2
----clientname2_projectname1
--misc
--personal
----jack
----jill
--tools
----modules
------internal_module1
------internal_module2
----scripts
------internal_script1
We don't do branching or tagging. The clientname_projectname folders contain the entire drupal root of a project (not including the files dir. If you do need the files folder, you can tar and d/l that separately). This way there's no confusion like "What version of Drupal am I supposed to use for this project". It also makes it easier to do security updates: Check it out from SVN, get a db dump, cvs up -dPr, confirm that it works, repeat on staging, repeat on production.
This is a lot like our
This is a lot like our setup, with the exception that we branch and tag extensively. Because of the number of engineers working on different feature sets for a project at the same time, we decided to create branches for every major feature, along with a maintenance branch. The branches get merged into trunk for QA and release to production. We tag after code is delivered to production, and bring a database snapshot back down for the engineers to use for their work.
My Take
trunk/www
--sites
----www.url.com/
--vendor
----drupalcore/ <--svn cp of drupalcore/current
------5.7/
------current/
------patched/
----drupalmodules/
------views/
--------5.x-X.X/
--------current/
--------patched
tag and branch at will. svn cp to grab vendor code. script to update vendor code with new tarbals. svn merging to update new versions of modules or core. everything goes in sites/ directory for custome themes or contributed modules. Patches go back to vendor directory if they are crucial for every project and didn't make it into core.
[1] http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion
Use build scripts to automatically tag out sites/directory everytime you need a new release. cp tar to production link a symbolic link to new tar.
Post new comment