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
qazwart_at_gmail.com
Received on 2012-03-12 17:33:25 CET