Here's why I don't think this is a feature for the Subversion project: * This is a Subversion client function and not a function of Subversion itself. Subversion thoughtfully publishes a Subversion API that developers can use to create their own Subversion clients. Notice that TortoiseSVN does not require a Subversion command line client unlike TortoiseCVS that requires a CVS command line client. Notice that Eclipse and AnkhSvn don't require a Subversion command line client. Anyone can create a Subversion client with the API, and if they choose, can create this type of functionality. Even if you put this functionality in the Subversion command line client, Subversion clients that use the API might not have it.
* Many continuous integration systems (like Jenkins) already have an option to remove non-versioned files before doing a build. The OP mentioned this as an issue. * It is traditional when you design your build system to make sure your built objects are stored in a temporary directory, so they don't pollute your source area. This way, it's easy to remove all of your built objects by simply deleting the temporary folder. In Java, I tell developers to create a folder called "target" under their project root, and store all built files and logs over there. This also ensures that you don't accidentally add built files into your repository. * It is traditional as part of your build system to have a "clean" target that does this. * It is easy enough to create a script to do this job for you. In Unix, if you don't have spaces in your file names, the one liner "svn status | awk '/^\?/ {print $2}' | xargs rm -rf" will do the job. * There are more serious features that Subversion is missing. The best known is a true "obliterate" command to remove obsolete revisions of files. For example, if someone commits a file that contains customer proprietary information, there's no easy way to completely remove that revision from Subversion. You have to take down the repository, and do a dump, filter, and load. I'd rather the Subversion team work on this issue, which involves the way the Subversion server acts, rather than this issue. This maybe why this has never even been considered as a feature. It really doesn't affect Subversion itself. This is something that the build system should be handling. In many open source projects, the source and build files are tarred up and distributed. What happens when the source is distributed, and you can't depend upon the version control system to do this for you? Nico Kadel-Garcia commented that this is important because his build contains many war files. You really should never check in built objects into Subversion. Instead, these objects should be stored in a release system where they can be downloaded as needed. Maven does this, but you can easily do this with Ant and Ivy too. Storing wars and jars in version control is an easy way to start off a project, but will cause major issues later on. Most of the time, you lose track of what version of the war or jar you're build is depending upon. Plus, no matter what version control system you're using, checking in and out binary based files is slow and takes up a lot of space. It gets to the point where your project is fighting a constant battle with stability. We have a project with five copies of the same jar file. Even worse, there are three completely separate versions of this jar in our project with two different ones in the same ear file. Every time something changes, something goes wrong. It'll take us months to clean up this mess. -- David Weintraub qazw...@gmail.com