[consulting] New project drupal workflow
Victor Kane
victorkane at gmail.com
Sat Mar 7 13:31:52 UTC 2009
Render unto Caeser what still uses CVS.
What I do is, since Drupal continues in its CVS depenedency, is to simply do
the following:
1. Check out every new Drupal site directly with a fresh CVS checkout. Let's
suppose I am in my home directory, and I want to create a fresh Drupal
document root in a subdirectory www. I do the following from my cheat sheet:
$ cvs -z6 -d:pserver:anonymous:anonymous at cvs.drupal.org:/cvs/drupal co -d
www -r DRUPAL-6-9 drupal
Then, to update that install to a new Drupal security release it is a simple
matter of running the following command from with the Drupal document root:
www $ cvs update -dPr DRUPAL-6-10
2. Use git or SVN for the www/sites directory on down.
If you like you can include a .cvsignore file in the document root:
sites
sites/default/settings.php
This has proven to be for myself, the single most simple approach.
Then, keep a current Drupal fresh install versioned with Git or SVN. Every
time you need to update modules, you execute the following command (assuming
for example that you are using the drush SVN opotion, leaving the drush CVS
support unchecked) from the Drupal document root:
$ drush pm refresh
$ drush pm update --svnsync --svncommit
Then just say yes.
And you can keep your "master" fresh install up to date, also updating core
with CVS as necessary.
Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com
On Fri, Mar 6, 2009 at 8:01 PM, George <g at 8vue.com> wrote:
> interesting, so each site you create is a git repos in itself and you
> just fetch and merge with these two repos'? i've just played with git
> for the first time today, and had similar actually! it's definately a
> workflow i'll look into - thanks
>
> Abraham Williams wrote:
> > I run 2 git repositories that i keep up to date. One contains core and
> > the other contains my frequently used modules plus a couple. When
> > there are updates I just update the 2 repos and then for each site I
> > run "git pull" and all of the new changes are pulled in.
> >
> > It makes keeping maintaining double digit numbers of Drupal sites a
> > lot less work.
> >
> > http://github.com/poseurtech/drupal-6-modules
> > http://github.com/poseurtech/drupal-6-core
> >
> > Abraham
> >
> > On Fri, Mar 6, 2009 at 18:18, George <g at 8vue.com <mailto:g at 8vue.com>>
> > wrote:
> >
> > so it's a terrible idea troy? well, it's kinda impossible to run
> > multiple sites from one installation, when it's for different
> > clients on
> > different hosts (but you realise that is essentially what i'm doing
> by
> > checking out the dirs). and please explain, why it'd be already out
> of
> > date? it's easy to upgrade drupal + modules in repos as no db has
> been
> > built yet - heck i could set up a script to auto-update the repos
> > daily!
> > yet you go on to explain you do the same by cloning a site
> >
> > installation profiles are VERY difficult to code quickly and also
> > poorly
> > documented (that's why they're covered in the back of drupal books
> > in a
> > short chapter!). some drupal functions are available, some aren't and
> > you need to include the relevant files as necessary. though
> > there's the
> > installation profile api which i haven't got around to testing
> > yet, but
> > apparently offers a lot of helper functions. but as for enabling
> > modules, from what i remeber, just specifying the modules in the
> > profile
> > will ensure they're enabled. simply copy the default profile to a new
> > dir, modify and test.
> >
> > i just hunted through the installation profiles and haven't found
> > a base
> > profile to work with, but take a look, there may be something
> > there for
> > your needs already.
> >
> > or, maybe someone here has a base profile they'd like to share?
> >
> > Christian Pearce wrote:
> > >
> > >
> > > On Fri, Mar 6, 2009 at 6:08 PM, Troy Arnold <troy at zenux.net
> > <mailto:troy at zenux.net>
> > > <mailto:troy at zenux.net <mailto:troy at zenux.net>>> wrote:
> > >
> > > On Fri, Mar 06, 2009 at 11:30:24PM +0100, George wrote:
> > > > I'm testing the idea of having a local repos of drupal and
> the
> > > essential
> > > > module (and some not so essential modules) and checking
> > out when
> > > i start
> > > > a new drupal project, and installing. of course this has the
> > > negative
> > > > that modules and drupal slowly fall out of date, but i find
> it
> > > > incredibly quick just to checkout, and start with the all the
> > > modules,
> > > > and take away what i don't want.
> > >
> > > It sounds to me like a pretty terrible idea to start with
> > > something that is
> > > already out of date. If you want a rapid start, why not
> > just run
> > > multiple
> > > sites out of one Drupal install?
> > >
> > > Also the drush module is pretty darn spiffy for quick module
> > installs.
> > >
> > >
> > > Do you have an example of this?
> > >
> > >
> > >
> > > > i'm thinking about combining this with an install profile to
> > > > automatiically enable the core essential modules cck /
> > views etc to
> > > > remove an extra layer of module enabling!
> > >
> > > > do any of you do anything similar? or do you have a different
> > > system?
> > >
> > > I have a Drupal project that periodically needs to get
> > cloned into
> > > a new
> > > instance. I ended up writing a Perl script to handle the
> > tedious
> > > parts of
> > > cloning the database, copying over and resources, erasing the
> > > un-needed
> > > content and writing a new settings.php. That's probably a
> > raunchy
> > > hack,
> > > but it was easier (for me) than learning the install profile
> > > system. It
> > > does require that you understand Drupal's database schema
> > very well.
> > >
> > >
> > > It's a slightly different question than what you're asking,
> > but for
> > > maintaining Drupal sites with a minimum of hassle I use a
> method
> > > largely
> > > based on David Grant's writeup:
> > >
> > <http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion
> >
> > >
> > >
> > >
> > > I pretty much do the same thing, but end up doing a bunch of
> > > configuration by hand. I too was hoping to learn the install
> > profile
> > > to create a baseline of modules I want all the time.
> > >
> > >
> > >
> > > -t
> > >
> > > _______________________________________________
> > > consulting mailing list
> > > consulting at drupal.org <mailto:consulting at drupal.org>
> > <mailto:consulting at drupal.org <mailto:consulting at drupal.org>>
> > > http://lists.drupal.org/mailman/listinfo/consulting
> > >
> > >
> > >
> > >
> > > --
> > > Christian
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > consulting mailing list
> > > consulting at drupal.org <mailto:consulting at drupal.org>
> > > http://lists.drupal.org/mailman/listinfo/consulting
> > >
> >
> > _______________________________________________
> > consulting mailing list
> > consulting at drupal.org <mailto:consulting at drupal.org>
> > http://lists.drupal.org/mailman/listinfo/consulting
> >
> >
> >
> >
> > --
> > Abraham Williams | http://the.hackerconundrum.com
> > Web608 | Community Evangelist | http://web608.org
> > This email is: [ ] blogable [x] ask first [ ] private.
> > Sent from: Madison Wisconsin United States.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > consulting mailing list
> > consulting at drupal.org
> > http://lists.drupal.org/mailman/listinfo/consulting
> >
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090307/443da168/attachment-0001.htm
More information about the consulting
mailing list