Home ›
Agaric's SVN repository structure for site maintenance and web developmentAgaric's SVN repository structure for site maintenance and web development
Submitted by Benjamin Melançon on April 11, 2007 - 7:19pm
ben@server:~$ cd drupal
ben@server:~/drupal$ svn add drupaldev
svn: warning: 'drupaldev' not found
ben@server:~/drupal$ mkdir drupaldev
ben@server:~/drupal$ mkdir drupaldev/modules
ben@server:~/drupal$ mkdir drupaldev/themes
ben@server:~/drupal$ mkdir vendor
ben@server:~/drupal$ mkdir vendor/drupal-contrib
ben@server:~/drupal$ mkdir vendor/drupal-contrib/modules
ben@server:~/drupal$ mkdir vendor/drupal-core-5
ben@server:~/drupal$ mkdir vendor/drupal-core-5/5.1
ben@server:~/drupal$ svn add drupaldev
A drupaldev
A drupaldev/modules
A drupaldev/themes
ben@server:~/drupal$ svn add vendor
A vendor
A vendor/drupal-contrib
A vendor/drupal-contrib/modules
A vendor/drupal-core-5
A vendor/drupal-core-5/5.1
ben@server:~/drupal$
Restructured the repository according to
http://drupal.org/node/118936#comment-220668
Custom modules should have both branches and tags as well as trunk once
we put one in there. Branches will correspond to different Drupal
branches as necessary, and tags to releases. Of course, once modules
we make become contributed modules I think we should get them from
Drupal like any other module.
Themes, meanwhile, might have branches for the customization for
specific sites, while we try to keep all general improvements in trunk.
Not entirely sure how to make this work.
The vendor branch for drupal core and contrib will contain untarred
modules ideally, with structure
examplemodule/drupal-5-1.0.x/examplemodule
But we can also get modules from Drupal.org's CVS if we label them here
well enough.
And for the consideration of branches, tags, and trunk for our
individual projects see SVN documentation and
http://ariejan.net/2006/11/24/svn-how-to-structure-your-repository/
Our projects are not entire sites, but rather the sites/exampleproject
directories.
So I'm not sure whether to svn::include modules into individual sites/
directories, into sites/all, or into a structure
apart from the document root which can be symlinked to in individual
sites/exampleproject/modules directories.
ben@server:~$ cd drupal
ben@server:~/drupal$ svn add drupaldev
svn: warning: 'drupaldev' not found
ben@server:~/drupal$ mkdir drupaldev
ben@server:~/drupal$ mkdir drupaldev/modules
ben@server:~/drupal$ mkdir drupaldev/themes
ben@server:~/drupal$ mkdir vendor
ben@server:~/drupal$ mkdir vendor/drupal-contrib
ben@server:~/drupal$ mkdir vendor/drupal-contrib/modules
ben@server:~/drupal$ mkdir vendor/drupal-core-5
ben@server:~/drupal$ mkdir vendor/drupal-core-5/5.1
ben@server:~/drupal$ svn add drupaldev
A drupaldev
A drupaldev/modules
A drupaldev/themes
ben@server:~/drupal$ svn add vendor
A vendor
A vendor/drupal-contrib
A vendor/drupal-contrib/modules
A vendor/drupal-core-5
A vendor/drupal-core-5/5.1
ben@server:~/drupal$
Restructured the repository according to
http://drupal.org/node/118936#comment-220668
Custom modules should have both branches and tags as well as trunk once
we put one in there. Branches will correspond to different Drupal
branches as necessary, and tags to releases. Of course, once modules
we make become contributed modules I think we should get them from
Drupal like any other module.
Themes, meanwhile, might have branches for the customization for
specific sites, while we try to keep all general improvements in trunk.
Not entirely sure how to make this work.
The vendor branch for drupal core and contrib will contain untarred
modules ideally, with structure
examplemodule/drupal-5-1.0.x/examplemodule
But we can also get modules from Drupal.org's CVS if we label them here
well enough.
And for the consideration of branches, tags, and trunk for our
individual projects see SVN documentation and
http://ariejan.net/2006/11/24/svn-how-to-structure-your-repository/
Our projects are not entire sites, but rather the sites/exampleproject
directories.
So I'm not sure whether to svn::include modules into individual sites/
directories, into sites/all, or into a structure
apart from the document root which can be symlinked to in individual
sites/exampleproject/modules directories.
Comments
On second thought
OK, first, above, SVN::include was meant to refer to SVN::external (or actually I think externals). But forget all that.
Thanks to thankfully dumbed-down Subversion tutorial for making that clear.
So we will follow http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
As this proud Canadian recommends:
http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion
Projects (sites) layout
Key aspect is that sites will be loaded from sites symlinked to a sites-live or a sites-test directory, which can exist happily apart from the rest of Drupal.
The only thing useful in my layout-- projectname/trunk/sitename
-- is that it allows an entire project to be checked out at once.
For instance, a project might consist of:
example.org
example.com (symlink to example.org)
example.net (symlink to example.org)
shared.example.org
shared.example.com (symlink to shared.example.org)
shared.example.net (symlink to shared.example.org)
sister-example.org
sister-example.com (symlink to sister-example.org)
sister-example.net (symlink to sister-example.org)
where shared.example.org shares tables with example.org
and sister-example.org may sometime in the future want to share tables with
example.org!
I think in a lot of cases it may be more convenient to check in and check
out all the related sites at once, by checking out projectname/trunk or
projectname/tags directly to the sites-test or sites-live directories,
respectively, if that's possible.
Thoughts? Thanks!
Database setup
Hi Dan,
Stefan may be automating this however he thinks is best but for the moment I'm creating databases with phpmyadmin - https://dev.grassrootsconnection.org/phpmyadmin/ - along the model Stefan suggested:
project_live
I did this for project "nome" (Nome, Alaska DJ Al Burgo's Bush907.com and other plans) by creating a user first, naming the user nome_live, clicking generate password and then 'copy' to move it up to the enter password fields, and finally checking off "create database with same name and all privileges"
SQL resulted, presumably with a real password when it ran:
CREATE USER 'nome_live'@ '%' IDENTIFIED BY '****************';
GRANT USAGE ON * . * TO 'nome_live'@ '%' IDENTIFIED BY '****************' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE
nome_live;GRANT ALL PRIVILEGES ON
nome_live. * TO 'nome_live'@ '%';I find that I've forgotten
I find that I've forgotten everything about SVN every time I turn back to it.
Discussion continues here:
http://agaricdesign.com/note/agarics-new-svn-repository-layout-play-well-contributing-cvs
Post new comment