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