• I create a local branch to working.
• I setup my External Tools in Eclipse to run my test suite.
• The output of my test suite gets committed to my local branch.
• I squash the local branch messages when I merge in to master.
• I add some insightful commit message for my master commit. Like, I haz changes.

So yesterday, I roll up my sleeves and prepare to dive in to an older project that smells like rotten potatoes. The plan of attack is to take this project and bring it up-to-date with Python 2.6, Pylons 0.9.7, and SQLalchemy 0.5.2 in the process of doing it, re-factor and extend where needed, of course letting the tests drive. I start my work and wand waving and 2-3 hours in I’ve removed about 200 lines of cruft and copy paste inheritance extended flexibility by further encapsulating some behavior using the Strategy pattern. I’ve got 47 tests (including functional doctests) passing and I’m green bar and happy with my time spent. So now time to merge this baby back in to master.

My test suite external tool performs the hg add . and I keep my .hgignore pretty up-to-date for Python projects, so I feel confident doing that. I open up the terminal to check out the change sets and start the merge and I notice I missed a binary format in my .hgignore. So I now have about 15 unwanted files staged for adding. Being lazy and knowing my last commit was when I just ran my test suite, I blindly run.

$ ^R hg revert <enter> <enter> (Ctrl-R, hg revert - shell previous command search)
$ hg revert -a --no-backup
# ...my work being destroyed because I was lazy and not paying attention
# whimpering

It is at this point my day goes from great to awful. I face palm as I watch the uncommitted changes I’ve been making over the last 3 hours get reverted. As I mentioned, this project was older, in fact, it was started before the migration to hg and I never updated the External Tools runnable for this project in Eclipse to do the new hg add / commits. So every time I thought I was committing when I was running the tests, I was in fact not. Fortunate for me, I did have some buffers open and was able to recover the end result in about 45 minutes of hacking, but I did lose all of my change history which was very very disappointing (not to mention scary).

So if I had any advice after this it would be ensure your older projects are up-to-date with how you do things now and they follow your current development process before you start refactoring. I guess the oneliner could be; When refactoring a project start with the tool set first.

Now to the SCM part. After about a week of playing with Github and Lighthouse, I found them both to be great products. They integrated well with each other and the tools for working with Git are available under every platform. If I didn’t already have my own server and experience deploying Trac and Mercurial I would use both these services without question. That being said, though I have enjoyed my time working with those tools, I’ve migrated my Github source and Lighthouse tickets over to a newly installed Trac 0.11, full circle.

End result. If you like tinkering. If you like managing your own installations or you have some customization/integration you would like to do, use Trac and Mercurial, otherwise use Github and one of the great ticket systems it integrates with; I enjoyed Lighthouse.

For fun, here is the circle of ticketing and scm life I’ve gone through over the last 6 years or so.

• cvs and PHP Ticket
• svn and home grown Python tickets
• svn and Trac
• Github and Lighthouse
• mercurial and Trac

Have to wonder what is next. A lot of people at work have been asking me why Github or mercurial? Why Wayne? True, that most of the time I am using the repositories for me, myself, and I (De La Soul), but the benefits extend just beyond handling version control for an arbitrary number of developers and clean merges. I’ll do a write up soon.

All the sourcecode for this site is now located at: http://trac.pieceopfy.com/pieceofpy
I’ll be updating all the old links through the other posts to reflect this. Fun.