Moving Back to Google Code for Simplicity of Subversion
March 15, 2008
What I learned was that since these are two open source projects that are really just a single developer -- me -- I wasn't realizing the goodness to be had in a distributed SCM like git. Since I work just off of trunk, I furthermore, wasn't hampered by subversion's marginal support for branching/merging. Lastly, the fact that I didn't have subversions nice incrementing integer revision numbers, left me missing that feeling of forward movement in seeing the number increment -- UUIDs are boring.
Then there was the github hosting, while great in many respects, it lacked a simple task management system. While I hadn't used one up until now, I got to where I wanted to log items that I was thinking about with my two projects and didn't have anyplace to put them other than a wiki page. I resorted to keeping a simple TODO.txt file in the root of my repo, which in some cases I think I prefer it, but overall, I like having the simple Google Code style item tracker.
So, I have reactivated those Google Code projects and updated the code with the changes that I had made in the git repository and deleted the repos on github. If and when, either of these two projects becomes very popular (doubt they will because of their very limited scope) then I might consider moving back to git and take advantage of all the wonderful things Malcolm points out in working with django via git. Until then, I'll enjoy the simplicity of subversion on Google Code.
PS: I noticed that Homebrew Coding has got an interesting article on using git, specifically the git-svn bridge, with a subversion based repository -- in this case a Google Code repository. I might have to check that out at some point in the future.