[support] multiple sites on same install was: Re: Upgrade to Drupal 5?

[Anton]

On 17/10/2007, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> How do you plug in core and contrib?
> You'd have your own repo cos you can't commit to the original repo.
> If you've to tweak core or contrib, how do you diff with upstream
> updates?

Core is handled by the svn vendor drop technique documented in the svn
book. We don't bother with that for contrib though - it would get too
fiddly.

And the long time between 5.x patch releases means that we seem to
hardly ever do vendor drops any more :)

We handled contrib by doing selected cvs checkouts (via a script) from
drupal.org into a svn like hierarchy (eg a subdir for each branch/tag
we end up using), and then checking that into svn. So a single cvs
update at the root dir updates the working copies of all the modules,
then we do a svn commit to apply them.

If any local changes we have made (which isn't many, and only tend to
be in unmaintained modules anyway) don't merge cleanly we deal with
the conflict then.

Having the different cvs branches/tags in different directories allows
you to pick and choose versions by changing your svn:externals path.
If you just want something to be stable pick a release tag, if you
want to track development pick a dev branch.

> You plug it in somewhere with a different tag and diff with the
> previous then you apply the tweaks to the new imported version, you
> open a new branch for all your projects, make the links to the new
> components, test.

Not really, it sounds like we don't have anywhere near the
customisations you have. merges take care of most things
automatically.

> Repeat for all the projects... maybe a bit faster cos you already
> tested in one place...

We're not really a consultancy, we just have a couple of projects for
us that don't get worked on full time. But I still think these
techniques would still help a consultancy with lots of projects more
than ad hoc development would.

>
> Do you have someone in charge just to keep versions in sync or the
> person that modify a module, is responsible for upgrading all the
> projects? Who/when do you upgrade contrib modules?

Yep - me. I'm the only one that knows enough svn/cvs and does any
module development anyway (plus I'm the company sysadmin). The others
who are/were designers who basically only needed to know svn update,
add and commit and stuck to working on our custom themes.

With a bigger team of devs, things could be automated more eg we don't
even need to use svn hook scripts yet.

> Start to sound interesting if you deployed a lot of automation... and
> nothing should stop you to forget to link projects to newer version,
> but at least you'll have a trace of what you did for other projects
> that were upgraded.
>
> Tricky things like modifying your own modules "on place" can be risky
> cos you'll modify all your projects.

Yeah that would be a risk for a larger team with lots of projects (ie
not us). I suppose education and branching would help. Does svn have
any scope for read-only working dirs?

> You should branch the module, modify one project to link to the new
> version, test it, change the link of all the others...
> The workflow should require a lot of discipline.

Doesn't any programming workflow? ;)

>
> There is still too much manual work in programming ;) wasn't it all
> about automation?
>
> what did you simplify in your svn layout? what is the exact workflow?
> including the launch of scripts?

We basically went from separate cvs/svn working dirs that were synced
by scripts to a combined working dir for both systems.

> Why 2 steps? tmp -> scp?

We do some cleanup in between to get rid of all the files that don't
need to go to the production site - eg translations, scripts, text
files etc. Not really required of course, we're just being picky.

Anyway...

This stuff isn't the be-all and end-all of setups, just something that
works for us. Hopefully some of the ideas can be adapted to suit
others :)

-- 
Cheers
Anton