I'm jotting some notes here for specific things to focus on when I work on the second draft of this section:
Include some diagrams to better explain the advantages and use cases of distributed source control.
It's probably easier to maintain drupal-core and drupal-contrib in their own repositories, rather than in a branch within the website's repository. Discuss the pros and cons of each.
Discuss the pros and cons of downloading release tarballs versus checking code directly out of CVS.
Discuss git hooks, and how they can be used to track permissions. Explain why git doesn't track permissions by default. Determine the best way to install scripts on multiple servers.
Add a section explaining how source control can also be used to manage database level changes. Expand upon backups taken in earlier section, and provide some background on where Drupal stores its data. Refer to the dbscripts project as appropriate. Added 08-22-08
Submitted by drew Reece (not verified) on Wed, 07/30/2008 - 00:16.
I'm currently using Drupal with Git, it's useful to see another persons interpretation.
I used concepts outlined on versioncontrol blog, where the core Drupal is cloned in its virgin state and then 'key modules' are committed to the second repository. This is cloned once mode to use for each production site, where the actual work takes place.
One thing is unclear to me, why do you begin with the cvs checkout? What are the benefits, other than being able to commit back to core. I avoided using cvs versions since I didn't like the cvs folders littering the project, and update module wouldn't update modules.
Do the cvs folders get pulled into every master branch? Also is the drupal core branch just the vanilla download from drupal.org, or is it a cvs version?
There are a few links I found useful, maybe they will useful to Shameel Arafin ?
Do you also have any methods for managing the permissions within Git, it doesn't do (much) by default and can cause problems with sites/default/files permissions.
"One thing is unclear to me, why do you begin with the cvs checkout? What are the benefits, other than being able to commit back to core."
Thanks for the feedback, I will be sure to clarify this in the writing. Tracking CVS is of questionable merit for a production website, though it would allow you to easily merge in changes prior to an official release. It also allows quick and simple command line updates.
"I avoided using cvs versions since I didn't like the cvs folders littering the project, and update module wouldn't update modules."
The CVS folders do not cause any specific problems, but the issue with the update module is a very good point. I will discuss this point in greater detail when I revisit this chapter. Thank you for highlighting the need.
"Do you also have any methods for managing the permissions within Git, it doesn't do (much) by default and can cause problems with sites/default/files permissions."
I will be interested in seeing if others contribute to the discussion on permissions. By default, Git very intentionally does not track file permissions. It does, however, support hooks which can be used for automatically tracking file permissions. A sample script is included in the git source, and was also installed on my server at /usr/share/doc/git-core/contrib/hooks/. In minimal testing this script seems to work very well, though it does add extra effort getting hooks set up with each repository. The simplest method I've found for setting up hooks is to modify your local git templates directory, or to specify an alternative templates directory when calling "git init".
When I revisit this chapter, I will be sure to include a detailed explanation of tracking file permissions. Thanks again for highlighting the need.
Submitted by Shameel Arafin (not verified) on Tue, 07/29/2008 - 15:00.
This is a wonderful tutorial you've written. I'm not particularly interested in the Drupal aspects, but I was searching for an article that would outline how to use git in a development-testing-staging-production web development environment, and your tutorial comes very close to what I was looking for.
Do you know of any other articles out there that deal only with git for production web dev? Diagrams would also be helpful.
Draft 2 Notes
I'm jotting some notes here for specific things to focus on when I work on the second draft of this section:
Add a section explaining how source control can also be used to manage database level changes. Expand upon backups taken in earlier section, and provide some background on where Drupal stores its data. Refer to the dbscripts project as appropriate.Added 08-22-08Interesting to see another view point on Drupal & Git
I'm currently using Drupal with Git, it's useful to see another persons interpretation.
I used concepts outlined on versioncontrol blog, where the core Drupal is cloned in its virgin state and then 'key modules' are committed to the second repository. This is cloned once mode to use for each production site, where the actual work takes place.
One thing is unclear to me, why do you begin with the cvs checkout? What are the benefits, other than being able to commit back to core. I avoided using cvs versions since I didn't like the cvs folders littering the project, and update module wouldn't update modules.
Do the cvs folders get pulled into every master branch? Also is the drupal core branch just the vanilla download from drupal.org, or is it a cvs version?
There are a few links I found useful, maybe they will useful to Shameel Arafin ?
A Drupal CVS git mirror
Git casts
Do you also have any methods for managing the permissions within Git, it doesn't do (much) by default and can cause problems with sites/default/files permissions.
I look forward to reading more of the book.
git, CVS, permissions, etc.
Thanks for the feedback, I will be sure to clarify this in the writing. Tracking CVS is of questionable merit for a production website, though it would allow you to easily merge in changes prior to an official release. It also allows quick and simple command line updates.
The CVS folders do not cause any specific problems, but the issue with the update module is a very good point. I will discuss this point in greater detail when I revisit this chapter. Thank you for highlighting the need.
I will be interested in seeing if others contribute to the discussion on permissions. By default, Git very intentionally does not track file permissions. It does, however, support hooks which can be used for automatically tracking file permissions. A sample script is included in the git source, and was also installed on my server at /usr/share/doc/git-core/contrib/hooks/. In minimal testing this script seems to work very well, though it does add extra effort getting hooks set up with each repository. The simplest method I've found for setting up hooks is to modify your local git templates directory, or to specify an alternative templates directory when calling "git init".
When I revisit this chapter, I will be sure to include a detailed explanation of tracking file permissions. Thanks again for highlighting the need.
Great tutorial
This is a wonderful tutorial you've written. I'm not particularly interested in the Drupal aspects, but I was searching for an article that would outline how to use git in a development-testing-staging-production web development environment, and your tutorial comes very close to what I was looking for.
Do you know of any other articles out there that deal only with git for production web dev? Diagrams would also be helpful.
Good job!
what specifically is missing?
Thanks for the feedback. Unfortunately I do not have any helpful links for you, I based this section on my own experience and the git man pages.
What specifically is missing in this article for your needs? What areas need more clarification? What areas could benefit from diagrams?