Using git with Acquia Dev Cloud / Managed Cloud

Acquia Hosting uses Subversion for code deployment. However, some clients prefer to use git instead. Those clients will either need to switch to Subversion or use some method to join together the two version control systems. Using git-svn would seem like a simple method. However, git-svn is used only when the Subversion repository is a canonical one and you want to use git for independent development. This article is concerned with when you're using git as the canonical repository and need to push changes from git to Subversion.

A better solution is to use git-svn commit-diff. This command eliminates the need to integrate directly with Subversion. Instead, it takes two git trees and commits a diff to SVN. The workflow is straightforward: Using your local git repository, or a clone since git is a distributed VCS, manually copy all of these files to Subversion. Be sure to make a note of the commit if you want to have as the initial SVN commit. When you're finished, commit there. Once you update anything in git, just use the last commit number like so:

git svn commit-diff -r <last_svn_revision> <old_commit_tree> <new_commit_tree> svn://svn-url

Git will make a diff between the last SVN commit and the latest version and commits it to SVN. The steps for this workflow explained in the remainder of this article.

The entire deployment will fail if anyone ever checked out files from Subversion. So you will first need to make sure that there aren't any .svn files in the git repository. You can do accomplish this by using a utility like find. Below is an example of how you might clean up a git repository. These lines are executed from the command-line:

git clone <git_url> svn_preparation

cd svn_preparation

find . -type d -name ".svn" -exec git rm -r {} \; 

git status 
git commit
git push

The first line above makes a clean git clone. You could switch to a branch you want to use. The second line changes to to the git clone. Using the find utility on the next line, coupled with the rm command, you delete all directories called .svn. Next, using git you retrieve the status and review all changes. If everything is fine, the next two lines commit the changes and push the results. When finished, look in git log and mark the number of this latest commit. Below is an excerpt from a git log:

commit 53501df5b2fbf0d30b014f118db41443513f7d39 # save this string somewhere 
Author: Jakub Suchy <jakub@dynamiteheads.com>
Date:   Wed Aug 18 12:57:51 2010 +0200

For ease of reading, references in this article to the string 53501df5b2fbf0d30b014f118db41443513f7d39 will be replaced with <commit_id>.

Make a checkout from Subversion and commit the current version of files from git there. You would enter something like the following from the command-line:

svn checkout svn://...url/

cd <new_checkout>

cp -r /old_git_clone_path .

svn add *
svn commit -m "Initial commit based on <commit_id>"

Do the same as with git: Type svn log and make a note of the subversion revision number. Here's an example excerpt from the results:

r29 | git | 2010-08-18 14:55:11 +0100 (Wed, 18 Aug 2010) | 4 lines 
Merge commit 'origin/store_locator'

In the example results here, the revision number is 29. You would make a note of that for later.

You're now ready to push changes from git to SVN. As a first step, update your git clone and then check the log. Do this by entering the following from the command-line:

git pull
git log

Make a note of the new commit identification string on which you want to base changes. This will be referred to as <new_commit_id> below. Execute the following from the command-line:

git svn commit-diff -r 29 <commit_id> <new_commit_id> svn://svn-url

The number 29 here is used since that's the number from the results of the last SVN log shown in the example above. This will be different on your system. Here's an example of how the line here might look with the <commit_id> and the <new-commit_id> replaced with realistic text and the URL filled in:

git svn commit-diff -r 29 53501df5b2fbf0d30b014f118db41443513f7d39 a1d7ad10111f747ce79394f2aa936f59f31dc6cd svn://bal-1.prod.hosting.acquia.com/repository/

The git scripts will now automatically commit all changes to Subversion. Make a note of the new Subversion revision. The <new_commit_id> now becomes <commit_id>. You can repeat this step as need. After performing steps above, you will be able to continue your development in git repository and push changes to Subversion whenever you want.

Remember to note of all the commit identification strings in your documentation. You will need them later when you commit changes again as you probably won't be able to retrieve them from history. The best place to put this information is in the project documentation every time you commit a changeset.