Mike Mason's a little bewildered, but blogging anyway...

Mike is currently…

trying to be Canadian

[ 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

Fri, 20 Aug 2004

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.

This might sound funny, after all source control has been around for ages, but your choice of source control software can really impact the benefits you see from it. CVS is the de-facto standard for developers collaborating on the internet, so if your source control system isn’t at least as good as CVS, you should really go look at why you’re using what you’re using. Paying big bucks doesn’t guarantee you’ll get a decent system — I’ve had bad experiences with StarTeam and PVCS, yet they both cost thousands of dollars. Subversion, the new open source replacement for CVS, costs nothing and works great.

Review your changes before checking in

I’m forever seeing developers check in changes without even eyeballing them for correctness. This is bad because you tend to check in extra stuff that you’d forgotten about, or even code that shouldn’t get into source control (System.out.println anyone?). A decent source control system should give you an easy way to review changes, postpone some changes for a later commit, roll back changes, etc. Reviewing your change also helps with the next part.

Commit logical changes with a decent log message

Often during a development session, you’ll change something fairly unrelated to the main task you’re working on. This is normal, and to be encouraged — if you see something that’s broken and needs fixing go fix it. New feature needed to help you implement your story? Go write it. But when checking in, don’t confuse the two. If your change includes a smaller, standalone change, check that in first, with a precise log message. Then check in your new feature.

Only change what you mean to change

As part of reviewing your changes, you might notice things you didn’t actually mean to change. Make sure you revert these changes, and don’t forget to re-run your test suite before checking in. It helps to have a fast build here, or to review your changes before running a big build.

Prefer smaller, frequent commits over big “end of week” code bombs

If your’re not checked in, it means you’re not sharing your changes with others. It’s important to frequently commit — if your changes conflict with someone else, you find out faster. If your changes include enhancements then another teammate might want to take advantage of them, and if you’re off work for some reason (or, yikes, your laptop gets stolen), your changes are right there in source control so others can use them.

Taking an extra little bit of care when using source control can really pay off. Weeks or even months after implementing new features or fixing bugs, your source control system can precisely tell you what was changed, by who, and (hopefully) why. Decent log messages, in particular, can save you hours of digging around in code trying to find something, and really help you communicate with other developers.

Posted 21:11, 20 Aug 2004.  

[ 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.