How often should a programmer commit to SVN?

Question

What is the general rule? When do you commit?

Answer 1

Commit early and often. It minimizes conflict resolution steps when working in a team. But don't commit anything that breaks your build. Ideally, continuous integration notifies the team when the build breaks.

Answer 2

I try to commit whenever I complete a 'piece' of work - as long as the code compiles, of course.

Answer 3

If working on trunk, I commit whenever I hit a milestone that won't impact my teammates. When working on a private branch, I commit whenever I hit a milestone I don't want to lose (I don't care if it even builds). For personal projects, I use mercurial and commit constantly. It all depends on what works for you and your team.

Answer 4

This is covered (and covered well) in an older post on best practices.

http://stackoverflow.com/questions/417599/svn-best-practices-working-in-a-team

I'm recommending checking out this post because it covers a lot of good ideas, not just how often to commit.

Answer 5

Commit when you have code you don't want to lose. That doesn't mean you commit to trunk, if you are developing in a team, you should avoid breaking things for others. How much code do you want to rework if your editor destroys the file? An hour or two?

Answer 6

I commit whenever I've done a unit of work: fixed a bug, added a feature, improved efficiency, etcetera. But I try to avoid long periods of silence. The advice in Don't Go Dark is worth reading.

Answer 7

It really depends on the situation.

• If you're working within your own branch or using git, fire away
• If there is an automated build process or continuous integration, you'll want to submit granular improvements
• If you're working concurrently with others on a branch, you'll want to submit when you have solid granular improvements, but on more of a 'milestone' basis.

Generally when I work it's in my own branch, so I follow 2 guidelines

• Commit if something is "complete". This is often used loosely - it can be a function, a class, a page, something that is complete enough that it can stand on it's own
• Commit if it's a "This works, but it's ugly" situation. Committing here acts as a fallback as I go back and revise my ugly fixes into something more elegant. Worse case, I go back to the working solution, however ugly.

Answer 8

When using Test Driven Development, I check in every time I've written a new unit test and gotten it to pass.

• Write test
• Ensure that the test is failing (otherwise the test is not effective or not needed)
• Write new code for this test
• Confirm that all automated tests pass
• Check In
• Refactor your work so that any duplication you introduced isn't there anymore
• Confirm that all of the automated tests still pass
• Check In
• Go to first step.

Answer 9

svn requiring commits to a remote server makes it hard to commit as often as you should, so I recommend trying out mercurial or git so that you can make local commits at all the times you want to and then send those commits to svn (via git-svn, or hg-svn) after doing your own cleanup if you must use a centralized svn repository.

The very fact that you're asking about how often to do commits implies that the centralized nature of svn is getting in the way of your workflow to some extent. You'll be glad of the benefits of a local machine repository once you get past the learning curve.

Answer 10

Programmers that comes from thin/distributed VCS or have used it before will commit in small changes or by features because local commit is very cheap. Then they would push to central repo once they need to sync. But because commit is very expensive with SVN, programmers that is using SVN (usually) commit daily which sometimes the changeset can be in a really big chunk and the commits might need be related by features. This is bad habbit.

So I try to take that best practice from DVCS usage into SVN aswell. Therefore I would commit to SVN by features so it would be easier for me to rollback once there is a problem in the changes.

Answer 11

What I usually do if I need to add a new feature or fix a bug, is to create a branch from wherever I need to, do my work there, get it code reviewed and than merge it back in. You could even break down your branches folder for each user (may not make sense if you have a lot of users) that each developer would keep their changes in.