Raise hands: Who's using VC with Drupal right now? Who's heard of or used VC in the past, but hasn't gotten that push to use it now. Who hasn't used VC, but wants to start? Who's feeling like ”VC what?”

Anecdote about designer who had to totally redo a weeks worth of work because she spilled coffee on her laptop. How hard was that phone call to make? Bottom line. Version control is bare minimum professional.

Also ”checkout” = get it the first time ”add” = add a file ”delete” = delete a file ”revert” = undo my changes Update applies just changes (patches), not whole files.

Why I prefer SVN: 1) Client-server. Access control and logging. 2) Revision number for the whole tree, not just by files. Client Server: CVS, SVN Distributed: Git, Bazaar Git: kernal dev – Linus specific Also: perforce, mercurial, Bitkeeper, Mercurial Clearcase, Monotone, MS Sourcesafe http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Lots of free hosting for open source: Sourceforge, google code, etc.

When people work together, conflicts can happen.

Drupal Version Control What is Version Control (VCS) Quick Start Version Control in Drupal Projects Slides at: www.michaelcole.com/drupalversioncontrol

What to version control? Everything *files*! Drupal code, contrib modules, your modules Drupal themes, artwork, mockups, designs Design docs, notes, anything you want to ”keep” Your database? It can be exported as SQL text... Version Control <3's text files Easy to ”diff” to see changes Easy to ”merge” changes together

Why Version Control? I lost the website Now I'm starting over VC offers more than ”avoiding pain”, but thats a start.

How Does it work? Only three basic commands: commit - ”Save this version” Takes current files and save it as a ”revision”. Each revision has a number. update - ”Bring back a version” Replace the current ”working” files with a previously saved revision. diff - ”Compare these two versions” Take two versions, and highlight the differences See all changes to a file – with comments! (All the rest is accounting)

What's ”best” system? Great way to see if someone likes to fight? Lots of options: CVS, SVN, Git, Bazaar, etc. For Drupal, two key systems: CVS For core and contrib Baked into drupal.org ”Old school” Subversion (svn) Popular for companies and professionals Inspired by CVS, built to address its issues Today we'll use Subversion.

How to setup server in 30 sec? Outsource your pain! unfuddle.com – 200mb free. 500Mb $9/mo cvsdude.org – 2gb. 2 users $7/mo. 5 for $20/mo assembla.com – 2gb. 40 users. $24/mo. Lots of other features This is when I understood ”why” the cloud. Want to DIY a server? It's not hard, lots of howto's on google.

What client tools? Command line for expressive input. GUI for expressive context.

Quick Start Subversion Walkthrough

Quick Start 1. Setup the server Signup, create a SVN repository, and get a ”url” Might look like one of these: http://host.example.com/svn/project https://company-svn.cvsdude.com/project svn+ssh://host.example.com/repos/project unfuddle.com, cvsdude.org, assembla.com E.g. http://michaelcole.unfuddle.com/svn/michaelcole_demo/

Quick Start 2. Initial Checkout Install client, then ”Checkout” URL to a folder on your computer: Command line: svn checkout [URL] [local folder] GUI:

Quick Start 3. Make Changes Congratulations, we have an empty folder. In the project folder, create a folder ”trunk”. ”trunk” will be our development branch. All our new work is done in the ”trunk” folder: /My Project/trunk/index.php Why bother with ”trunk”? Keeping ”trunk” let's us ”branch” e.g. /My Project/branches/version1/index.php ”Branches” let changes happen in different ”areas”, that can merge back together.

Quick Start 3b. Why Branches? Different codes will have different timelines: Drupal 6, Drupal 5, Drupal 7 Security fix in Drupal 6 - /branches/v6.15 Backport to Drupal 5 - /branches/v5.15 Continue development of Drupal 7 - /trunk/ Experiment with Propel object persistance layer in Drupal 8 - /branches/crazy Each of these is a branch of time in version control Each moves forward independently Changes can be moved between them Useful to look at changes go back in time

Quick Start 4. Your first commit Ok, we created our ”trunk” and added index.php Command line: svn status | grep "^\?" | awk "{print \$2}" | xargs svn add svn commit GUI: Add a ”log” message here List of changes. Double-click for details

Quick Start 5. Teamwork 2+ people can work on repository at same time. Share the checkout URL, and account info As often happens with people, conflicts can arise If two people change a file at the same time, it's called a conflict To avoid conflicts: Update before commit Commit small. Commit early. Commit often. Last person to commit ”looses” and has to resolve conflict.

Quick Start 6. Conflict Resolution Svn can ”merge” changes to different parts of same file without pain. (svn loves text files) Two changes that overlap cause a ”conflict” Step 1: Relax. Close email. Turn off phone. Step 2: Compare the two changes. Step 3: Decide which version to keep keep theirs (deletes your changes) keep yours (delete their changes) Edit the file manually (hand merge) Commit small. Commit early. Commit often.

Quick Start 7. Review log Version control is not just a backup. It's a multi-dimensional file system, through space and time.

Drupal Specifics Version Control in Drupal Projects Many ways to do this. Each has merrit. Here's how I do it.

The Problem: You → Server Test Server Staging Server ”Email the changes” SSH/FTP Other Developers The Client QA/Your Boss Dev Box Production Or Host FTP File Sharing File Server ”Oh, just a small change for production” ”Wait, where'd my change go?” Abbot: Who's on first? Costello: Exactly! What's the simplest thing that could possibly work?

Dev/QA/Prod Environment: Benefits of Version Control: One central place for changes One way to move files (commit and update) Official ”version” Backups Commit log of changes and comments Know your version: bugs, testing, etc. VC harder to use than bug tracking website. This ”barrier to entry” prevents casual changes.

Basic Approach Version control is all about the files: Code - Drupal, modules, custom modules, themes public_html/<drupal> public_html/sites/all/<modules and themes> Site Files - uploads/images/etc: public_html/sites/default DB - Backup with ”Backup Migrate” module public_html/sites/default/files/backup_migrate

To ”commit” To commit: 1) svn update 2) Backup database with ”Backup Migrate” 3) svn add [files] 4) svn commit On dev box, can use GUI. On production/staging use command line.

To ”update” To update to a revision: 1) svn update 2) Restore database with ”Backup Migrate”

Organizing Files and folders: <repository>/project/ trunk/ public_html/ ← Web server root sites/<modules and themes> sites/default/ ← site specific files sites/default/files/backup_migrate/ ← SQL private_html/ ← https root (if needed) private/ ← Notes/docs/art/etc lib/ ← Unserved code branches/v1_1/public_html/...

Who's working where: Who's working on what branch? Developers: https://svn.repository.com/project/trunk Production: https://svn.repository.com/project/branches/v1_1 Staging: https://svn.repository.com/project/branches/v2_beta1 Test/QA Server: Any of the above

Assumptions: Servers (command line): ssh access svn command line Not uncommon in shared hosting: Dreamhost / Simplehelix / MediaTemple Hint: Create a svnadd alias in your login profile: Create/edit ~/.bashrc (or ~/.profile). Add this line: alias svnadd='svn status | grep "^\?" | awk "{print \$2}" | xargs svn add' Development (GUI): Best effort to make environments the same Use config files where needed

Observations: Solves these problems: Portable. Easy to duplicate a config for testing Keep uploads/graphics/etc in sync with database Also... Make symbolic links where needed on production server. E.g. www → public_html drush could replace ”Backup Migrate” for simpler scripting Create a seperate ”sandbox” repository to check in files and code that are not part of trunk.

Gotchas! Does not solve these problems: Manage config changes in database dev → QA → staging → production Apply manual process or see ”Feature” module. Large quantities of files/data Use svn's ”ignore” feature to skip certain files Data security issues (HIPPA, PCI, etc) now happen on your dev box. If this is you, don't checkin production database Great for copying prod database to dev. Please don't copy dev database to prod server

Questions: It's Over! It's alot to cover. Many approaches. Questions?