I have addopted a practice of only committing one bug fix at a time into the version control system (in my case Tortoise SVN). This can take a bit more time but it solves a lot of problems and saves a lot of time later. I find if the code ever needs to be merged it is a lot easier, especially being able to test the bug, merge the code and test that the bug was fixed. If the code ever has problems one can identify exactly what code was changed for a particular bug fix. It is also the cleanest approach because when you checkin your changes you know exactly what you are changing and you won't forget any changes breaking the rest of the team. The trick is human error happens so I like to reduce it when possible.
What practices have you addoped when working with version control systems?
Friday, June 29, 2007
Good Practices When using Version Control
7 comments:
Now there's a best practice that CollabNet should espouse! I love it!!
It sounds like your pain with merging in SubVersion (common story) is forcing artificial development habits. You're right that having all logical file changes as a *single* transaction is easier to manipulate. But think of all the ancillary effort (i.e. testing/fixing/testing/...) you need to make absolutely sure that the defect is entirely fixed -before- you commit any changes! That's what I mean by artificial.
Taking a step back, when fixing a defect you should be able to commit as often as needed to save your work and, more importantly, into a private area to prevent polluting others with partial fixes. Also, you should be able to 'group' those 'n' commits as "the fix".
There are a few tools on the market that do this out of the box... I'm most familiar with AccuRev as they have Private Workspaces for developers and Change Packages to envelope 'n' atomic transactions to fix a bug (BTW, Change Packages are tied directly with your issue tracking system).
HTH - dave
I just looked and there is a best practices over at http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html under the heading Commit logical changesets with a very similar idea.
Dave,
The bug doesn't actually have to be entirely fixed before you commit. I just don't like to commit two bug fixes in one transaction. If two bug fixes are similar and are on the same code then it makes sense to have them grouped together. But if they are in different parts of the product and for whatever reason aren't related, then I try to separate them. But this isn't an "artificial development habit" any more than cleaning one's desk. This is just a pragmatic workflow that I have found works for me. In the end the same amount of testing should happen, the only extra overhead is committing changes to the version control system more often. This is a simple approach and I like simple.
I definitely agree with "fix no more than one thing per commit".
When there's refactoring to be done, we also tend to do the refactoring on its own commit, and then do another commit for new or fixed code. It's much easier to look back at the diffs and see the actual behavior change when you didn't also sort the uses clause, rename a class, and extract a method on the same commit.
Actually, we've started getting to the point where, instead of asking "have we done enough that we're ready to commit?", we ask "is there any reason not to commit now?" Commits are cheap (we also use SVN/TortoiseSVN), and it's better to do several small commits rather than one big one. When the automated tests break, it's easy to track down which commit broke them, and if it was a small commit, it's that much easier to fix.
That's a fine idea when you're part of a large team, and your job right now is to close out a large number of bugs.
Some other development tasks (such as feature implementation) should be done in much larger chunks.
WP
WP,
You make a good point. Whatever the work one is doing should be commited to the version control system in a logical fashion for the task at hand. No two tasks are the same, so as anything one develops good techniques with practice.
Post a Comment