I spent yesterday over at Rory’s writing some code at his new and internet deficient flat.

As mentioned I took a local git clone of my subversion repo with me so we could branch / commit and generally stash our code out of harms way as we progressed.

git-svn works smoothly and isn’t too much of a mental stretch.

WARNING: learner driver steering. Cribbed heavily from Andy Delcambre though all mistakes are mine alone.

At the risk of repeating everybody else in the Rails development space, but for my own edification here is my git-svn workflow:

1. Make your SVN repo git proof: go and find all your empty directories like log and those things and commit a .gitignore file in them because they’ll get removed by git otherwise. You can put a useful ignore pattern like *.log in some of them if you care to but sometimes like vendor/plugin it is just necessary to create the .gitignore file.
2. Take a copy of the code before leaving the civilised world for far away and internet impoverished Clapton:

   
mkdir pollthing-git && \

cd pollthing-git && \

git svn init -s svn+ssh://panic.gatezero.org/Users/tim/svn/pollthing && \

git svn fetch && \

git repack -d


   You’ll find yourself in your working directory along with all your code and the master branch is active.

3. Start working on a new feature by creating a new branch and switching to it:

   
git checkout -b add_an_unsubscribe_for_mail


   That will tell you something like this:

   Switched to a new branch "add_an_unsubscribe_for_mail"

   Now hack away to your heart’s content.

4. You’re going to change and add a bunch of files.

   For new files you have to add them to the repo just like svn:

   git add foo

   For changed files you have to add them too!

   git add bar

   So that’s way different from SVN.

5. Don’t be afraid of commitment. You’re done with your coding on this feature.

   You can add changed files at commit time and this is probably a good reflexive practice so no file is left behind:

   git svn commit -a -m "I'm not going to forget about that file I modified by using this -a flag"

6. Hrm… write then rewrite, okay… I just re-read what I’d written about sending changes back up to the SVN repo and it wasn’t clear. So I hope this is clear:

   To send your changes back to the repository from your current branch:

   Pull the latest from your SVN repo into this branch:

   git svn rebase

   Fix any conflicts and then send your changes to SVN:

   git svn dcommit

   Done.

   Okay, so what was it that I was trying to say wasn’t so clear?

   Right, now, getting things back into SVN isn’t hard but there are a couple of schools of thought. All your changes are in the add_an_unsubscribe_for_mail branch.

   Either, pull changes from SVN down into this branch and deal with merge there and then commit. This is probably the best way to go if you have normal access to SVN and you’re just using git-svn to learn git because the git-svn manpage states:

   For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server, and avoid all git-clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git-format-patch and git-am, or just dcommiting to the SVN repository.

   Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you’ve made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.

   Or, merge the local changes from your add_an_unsubscribe_for_mail branch into the master branch and then merge SVN changes at that point and commit to SVN from there. This is what I did yesterday and it worked well. I branched and then merged each feature I worked on from and back into master before working on the next. THIS IS PROBABLY NOT A GOOD IDEA THOUGH because of the caveats above.

   Next time I’m away from my SVN repo with git svn I’ll just branch once and commit to that serially and then send that branch back up to SVN when the time comes that I have connectivity again.

This entry was posted on Tuesday, April 22nd, 2008 at 1:06 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.