21–30 of 52 posts
Earlier quoted context omitted.
Managing the codebase is straightforward -- that's what git's designed for. My question was more about the actual site contents, which will reside in the database. Can you use git for tracking changes to the contents?
Probably not. You're better off logging your MySQL queries and filtering out the UPDATE, INSERT, and DELETE queries for the tables you're interested in.
I use Fabric with mercurial to achieve a similar effect typing "fab prod deploy" - see Steve Losh's blog posts or bitbucket.org/kevinburke/goodmorningcmc
I've played with this - in the end I ended up using custom scripts and/or Capistrano scripts (along with git of course) to handle actual deployments. It provided more control and more features, while still letting me leverage git.
Earlier quoted context omitted.
Managing the codebase is straightforward -- that's what git's designed for. My question was more about the actual site contents, which will reside in the database. Can you use git for tracking changes to the contents?
Probably not. You're better off logging your MySQL queries and filtering out the UPDATE, INSERT, and DELETE queries for the tables you're interested in.
If it is a small amount of content, such as a handful of pages for a brochure site, putting them in a feature might be best.
If it is a site where customers or visitors generate content on the site, then periodically re-initialize your dev and staging environments with copies of the live DB, running it through a script to anonymize all the user info and change passwords and etc.
If you want to create content on your dev and move it live, then doing a full database copy and moving it live, with settings that are particular to live overridden in settings.php, is probably the best way. I advise against this, basically you are re-launching the site for every change.
If you are truely desiring to be able to create content in multiple different places and move it to live, then probably the best thing to do explicitly program and configure for that, by specifying feeds of the content and setting up the different sites to ingest each other's feeds.
I do something similar, but I keep the "central" repository in another location on the server and pull from that.
Earlier quoted context omitted.
To elaborate on dolinsky and the article, if your web server is doing a "git pull", it means it has ssh access into your workstation. If someone breaks into your web server, this means that they have ssh access into your workstation as well by simply using the keys on your web server. This is bad, very bad. If you push to your web server, only your public key is exposed if your web server is compromised.
Not necessarily. If you run an ssh-agent locally and configure ForwardAgent to 'yes' for connections to your web server you can ssh to your server and use ssh from it without actually putting your private key on it. I'd still recommend pushing to a server though.
What about using git to backup an entire hard drive? Maybe using bitbucket (or github if you don't mind sharing your data with the world). Living on the cloud has never been so easy :-D
Earlier quoted context omitted.
Probably not. You're better off logging your MySQL queries and filtering out the UPDATE, INSERT, and DELETE queries for the tables you're interested in.
I would advise against that. There are too many places in he mess of tables of data configuration that might refer to specific auto-increment id columns were things will get out of sync. Basically you are trying to do MySQL replication on specific tables only, but there are too many relationships among all the tables. If it is a small amount of content, such as a handful of pages for a brochure site, putting them in…
Earlier quoted context omitted.
that's what we do in conjunction with http://drupal.org/project/features , bugs aside it works well but what you want in code and what you want in the DB will vary from page to page and feature to feature so often just manually redo stuff (in dev env and then again in production) because deploying changes by code is more effort then its worth.
Managing the codebase is straightforward -- that's what git's designed for. My question was more about the actual site contents, which will reside in the database. Can you use git for tracking changes to the contents?
If you want to create content on your dev or staging site and push it to production, check out the deploy module: http://drupal.org/project/deploy
Tracking changes to nodes in production is probably best left to Drupal's built in node versioning system. Diff (http://drupal.org/project/diff) is a handy module to track changes between revisions and if you want a little more advanced workflow check out revisioning (http://drupal.org/project/revisioning) and workflow (http://drupal.org/project/workflow). Good luck!
I do something similar, but I keep the "central" repository in another location on the server and pull from that.
That's what I do, except I use svn rather than git.
With GIT thats a moot point in the linked article so long as you are using branches for everything and remembering to push them as well, but sometimes I just want to fix something quickly and do so without a branch. I dont care what people say when you start storing a lot of stuff in GIT a branch can take some time to process.