On 17/10/2007, Ivan Sergio Borgonovo mail@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 :)