I often hear discussion about how often developers should commit their work to the central repository. Some say that you should only commit when you’re next ‘release’ is ready. Others say that you should commit every change you make in your code. There are even people who say you should commit your changes only at the end of the day.
All wrong! There is no such thing as ’the way’, but there is a thing called best practice and that’s what I want to talk to you about. How often and what should you commit to your Subversion repository.
Actually, it’s quite simple. If you use a tool like Trac or any other ticketing tracking system you have already got a great starting point (given, of course, that you add ’things you need to do’ to your tracker).
I split my development activities into small atomic actions. Normally these actions take up a few minutes to an hour of your time. Besides the fact that these atomic actions are managable, they also give you a sense of satisfaction because you can complete quite a few of these smaller actions every day.
All right. You have these atomic actions. I grab my code, perform the atomic actions and when it succeeds, I comment my changes back to Subversion. This always closes a ticket in my Trac system and most of the time refences the ‘big picture’ ticket.
Here’s what I mean.
Big picture ticket: “Create an accounting system for users”
Atomic Action ticket: “Create and customize the user model and unit tests” Atomic Action ticket: “Install acts_as_authenticated plugin”
So, I start with my code and first I install the acts_as_authenticated plugin. Great. Commit that. This takes a few minutes at the most.
Next, I create and customize the user model and unit tests. When that’s done, I commit my changes again. As you can see, I’ve already closed two tickets (and got that warm satisfactory feeling).
Okay, you get the picture. Why would you work like this? Subversion allows you to keep track of changes in your code, but it doesn’t force you on how ofter or when you track changes.
The most logical way of keeping track of changes is atomic actions. If you decide later that you don’t want the installed version of the acts_as_authenticated plugin, but a later release. You can see what files were added when you installed the plugin.
By using atomic actions you create atomic changesets in Subversion. This way you can easily jump between different states (revisions) of you code without breaking things. It keeps your code working and it allows you to easily track changes you made and to what purpose.