The concept of "backup" is incompatible with the idea of Revision Control, which is designed to avoid backing up. Instead, the whole history of all changes is saved. Of course, you can backup the whole codebase, and you can create tags, which is not a part of Subversion, but is a common practice. The tags are not saved on each build, they are saved on important steps, such as releases, or some steps when you change the version of your software.
However, you may mean simple commit of the most recent changes. And still, I'll strongly recommend not to include even the commit to the build project. You should better isolate development, batch build and commit to code repository. Normally, a developer builds the solution several times, tests it preliminarily, and, after making sure the changes make sense, commits them to the repository. The idea is: commits could be quite frequent, sometime in a few minutes after each other, but they should be consistent, never disrupt the work of other developers of the same solution (mistakes happen though, but I'm talking to principles). Each time a developer creates a consistent set of changes of fixes in one or very few aspects of the code, it makes sense to commit. At the same time, in the middle of just one such change, a developer may need to do full batch build several times. And what, do you want to commit some possible garbage?
I would advise you to review your development cycle instead. At the same time, batch commit is not a problem at all. Just read the Subversion client documentation (regular console-only client, of course). But, first of all, think at using just a good client. You bay never need such batch. Better think of perfect comprehensive batch build, a must for cultured development cycle.
—SA
Submit an article or tip