User login

Agaric's SVN repository structure for site maintenance and web development

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.

if you wish to only update a subdirectory of your local copy, you can do the update from within that directory.

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!

  • ben

svn co http://repourl/projectname/sitename/trunk

Stefan Freudenberg (StfnFreu): My experience suggestes that this is more
intuitive then having trunk in the middle because from a project standpoints
the projecs consists of sites not of trunk and tags.

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

The content of this field is kept private and will not be shown publicly.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • You can use Markdown syntax to format and style the text. Also see Markdown Extra for tables, footnotes, and more.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <blockquote> <small> <h2> <h3> <h4> <h5> <h6> <sub> <sup> <p> <br> <strike> <table> <tr> <td> <thead> <th> <tbody> <tt> <output>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.