[consulting] New project drupal workflow

Abraham Williams 4braham at gmail.com
Sat Mar 7 08:22:10 UTC 2009


I don't actually merge the two repos. I just check out the modules one in
sites/modules. I probably should merge them though.

On Fri, Mar 6, 2009 at 19:01, 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
>



-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090307/e902a915/attachment-0001.htm 


More information about the consulting mailing list