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

每当我完成一件“工作”时我都会尝试 - 只要代码编译，当然。

Answer 3

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

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 4

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 5

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
• Refactor your work so that any duplication you introduced isn't there anymore
• Confirm that all of the automated tests still pass
• Go to first step.

Answer 6

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 7

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 8

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

如果我需要添加新功能或修复错误，我通常会做的是在我需要的地方创建一个分支，在那里完成我的工作，检查代码并将其合并回来。你甚至可以分解你的每个用户的分支文件夹（如果你有很多用户可能没有意义），每个开发人员都会保留他们的更改。

Answer 12

General rule:

• after doing an atomic change that makes sense.

An atomic change: is a "logical unit" change, which you feel easy to write it in the commit's comment.

Makes sense: It includes safe to update - compiles and not break features - which has the logical change you are not afraid to say in the comment.

When do I commit: When I made some change as mentioned in general rule, and I try to do it more often.

Some more good practices can be found here: http://ducquoc.wordpress.com/2011/06/09/svn-best-practices/