The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Source/Version Control Best Practices?

Recently I was wondering if there is some document, blog post, article or something written by some expert in the field about best practices of using the source control systems. By source control systems I mean not particular product but source control as a whole, as a concept and its best practices of use. These are the things that concern me most:

* How often to check-in/commit changes to the main repository? That is, how granulated the changes have to be?

* How to handle the case when one in the process of development wants to save the state of the source code after adding some experimental new code, but does not want these changes to be treated as official version of the repo? In other words, how to distinguish between experimental/in-progress commits and the more 'official' commits (not necessarily internal versions, releases, etc)?

* What and how much to write in the text description of the commit? How to refer to the changes - I mean for example, names of changed functions, classes, modules, libraries?

That is it for now, I hope that some other aspects of practical source control usage will emerge in the discussion.
Monday, June 23, 2008
Here is a start. Check out the source control HOWTO
Bart Park
Monday, June 23, 2008
Some of these will depend on factors specific to your situation, but in general I would suggest:

* Commit early and often. The granularity I tend to use is about the level of one "task completion", where a task should take no more than a couple of hours time of implementation. If I have three specific things to do to one class (three bug fixes, for example), I fix one, verify and then commit. Lather, rinse repeat.

* Branching can get ugly, but this will be highly dependent on your specific situation. There are systems which lend themselves to branching (distributed version control (like git or Mercurial) is said to be excellent at this), but they seem to be tailored more towards highly skilled developers than standard corporate IT.

* Describe what you did in your commit logs, not what you changed. Your source-control system should have a way to view changed files (and possibly source diffs) between two versions of the codebase, so it's redundant to specify this in your commit. What is not redundant, though, is an accurate, succinct description of what changed so that you can read it a year later  and easily decide whether that's the version you're looking for.

* Update regularly. It's silly, but you should encourage / enforce a culture where developers don't let their local repositories get stale. When someone who hasn't updated over the course of a busy month suddenly updates, there will be problems. Fixes in progress may no longer be relevant, things may need massaging before they will merge, etc. Don't let your local codebase get stale.
BrotherBeal Send private email
Monday, June 23, 2008
This is a SCM patterns/theory book that is not tied to any one implementation.
Monday, June 23, 2008
Christopher Wells Send private email
Monday, June 23, 2008
I really like this one:

Really doesn't have much to do with agile development specifically. It's a great tutorial about how and when to use branches, when you should check in, when you shouldn't, and good rules of thumb.
Chris Tavares Send private email
Monday, June 23, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz