Source control in new projects

Question

I'm working on a project by myself at work and I know eventually it will need to be stored in our SVN. My question is what do I do to store it in SVN if I'm starting from scratch? Do I only commit stable complete builds or commit when I feel a certain module reaches a certain milestone?

Answer 1

Commit early and often. This minimizes conflict resolution steps when working in a team. It's also good practice when working alone so you have a history that you can roll back to if you find you've moved in a wrong direction.

Answer 2

Start with your current code, add it as "initial commit".

Answer 3

Initially:

Commit what you have as the initial version.

You will want to commit often as you develop. You will want to make sure what you commit is buildable though.

You can always checkout a particular revision of your code, and as you reach milestones you can tag your repository as well.

Once you have working code:

Once you have your main code stable, you can start to do branches for bigger changes. See my answer here for more information on branches vs trunk for development.

By working in branches you can commit as often as you want and you won't have to worry about committing bugs to other people working on the project. They will have to work through the same problems that you are working through.

Also if they can't build what you commit, that wastes their time as well.

When to be careful about committing to your trunk:

Once you have multiple developers on your project be careful about when you commit to your trunk. By committing something that doesn't fully work, you are waisting the time of other developers on the project.

Committing often is good:

Committing often is good, whether into a branch or your trunk because...

• You can track your changes via the SVN log.
• You can go back to a working version if you break something.
• If you lose code you will have a backup.
• It is easier to merge in other people's changes. If you are working out of branches for a long time you can rebranch and merge your changes into that new branch.

Answer 4

Commit early and often. Generally, commit stuff that compiles - but sometimes, if you're about to embark on some disruptive changes to your design, check in the version so you can go back to your 'last nearly stable' version. While you're working solo in your own repository, it won't matter much; you won't affect anyone else. Once you're using the communal repository, make sure you isolate your own development from anything that can break others work; use branches.

Answer 5

I would recommend to commit often. It will make difficult to go into conflicts if your colleagues also do it, and the source control willl act as a back-up of the project.

I think the absolute minimum is to commit once per day, and the more often the better! The ideas is that if it compiles it can be committed.

For larger teams there may be also a specified time on the day to do commit (like for instance before lunch to allow an automated build to process).

Answer 6

Commit often, and commit everything that won't break your build. By "build", I mean whatever compiles, passes unit tests... whatever your successful build criteria may be.