Boy Meets World

Mike is currently…

snowboarding in Banff

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages

Tue, 30 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

When To Commit

I’ve been using source control since my first year at Uni, when I was doing practical lab work on my own machine. I wanted the computer to do the hard work remembering what I’d changed and when. RCS was my first attempt, but this uses your working directory to store all your revisions, and a misplaced recursive-delete knackered my mornings work. CVS worked a lot better, then at work I fell in love with Perforce, and more recently have been looking at Subversion – it really rocks. Real atomic commits, offline diff and revert, branching and tagging as directory operations, and it’s Free.

Tim Bacon gave me some interesting feedback on my entry about source control as backup. I’d mentioned that you could theoretically commit every time you’ve got a green bar, but tempered this to “significant” green bar. I wanted to note that you shouldn’t really commit every time you make a change, because your source control system will get littered with commits, possibly making future review of what has changed more difficult.

Tim’s comments prompted me to revisit why I said this. Why not commit on every green bar? Why not have an IDE that automatically commits every time you perform a refactoring? Surely organisation of changes is source control’s job, not mine. We’ve got a problem because we’re providing commits at too granular a level. We need a way to group those commits into bigger changes associated with functionality or bugfixing – these are the “significant green bars”. Perforce has a mechanism for tagging each commit with a ‘task’ to which that commit relates, a feature which can be used, for example, for bug tracking integration. This would work, as long as we could then choose granularity when browsing file history.

Something that provides a pretty good balance between the two is IntelliJ’s “local VCS” feature. It tracks your changes locally, storing several days of history, and has full integration with IntelliJ’s refactoring features. What’s more, it automatically applies labels whenever you compile, debug, run tests, etc. The actual labelling is fully configurable, and I can browse my granular changes locally, whilst committing bigger changes through my ‘official’ source control system.

Posted 13:51, 30 Sep 2003.

[ permalink ]

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.