When a developer has finished making changes in their working copy, they need to commit their changes to the repository so that the other developers in the team can see the changes and make use of them.

In , a commit is an atomic action. A commit can contain any number of changes to files and directories including edits, additions, deletions and moves. The atomicity of the commits behaves just like in a database – either they all complete or they are all rolled back.

Each commit to a repository creates a new revision. A new revision is identified by a revision number that is one greater than the last revision number. A newly created repository that has had no commits to it has a revision number of zero.

It is important to remember that revision numbers apply to the entire repository, even if multiple projects are hosted in the same repository. Another way to think about it is that revision N represents the state of the repository after the Nth commit.

In addition, Subversion does not apply individual version numbers to files, which is different to most other version control systems. When Subversion users talk about “revision 5 of file Foo.java”, they really mean “Foo.java as it appears in revision 5”.

In a repository with multiple projects being hosted, this revision numbering can cause confusion and consternation to some developers. For example suppose you have this situation – you have 2 projects, one being actively developed and the other only being changed rarely for maintenance, but both in the same Subversion repository and they are the only projects in the repository. A developer makes a change to the maintenance project and notes that the new revision number is 30. He makes no changes to the maintenance project for a month. He then makes a new change to the maintenance project and notes that the new revision number is now 87. How did it jump from 30 to 87 if no changes were made to the project? Remember the revision number is a repository wide value. So in that month we can deduce that there were 56 commits to the other more active project (numbered 31 to 86).

The revision number is arbitrary and you should really not worry about it being consecutive for any single project. However, if you are really truly bothered by it, you can go with the one project per repository approach. However, keep in mind that even if you do that, commits on different branches of the same project will still also increase the revision number, so the revision numbers for any one branch are still not guaranteed to be consecutive.