I suspect TortoiseSVN uses the official Subversion client code under the hood. There's no way they'd re-implement a whole SVN client from scratch.
Not many third-party SVN clients (any?) implement the SVN client-side implementation themselves. They use SVN libraries for that - something like SVNKit (http://svnkit.com/)
In fact, the Subverson project discourages other clients from directly manipulating the contents of the .svn directory. To quote http://subversion.apache.org/docs/release-notes/1.7.html:
"Subversion 1.7 working copies have just one .svn directory...This directory includes (among other things) an SQLite-backed database which contains all of the metadata Subversion needs for that working copy...We highly discourage external tools from modifying the data held in this database, as such modification is likely to result in working copy corruption."
Other people have commented on the fragility of the "clean" task of a build script. If you use things like NuGet and Bundler in codebases, they result in multiple directories that need "cleaning" - e.g. .\vendor\bundle, .\packages etc. You'd be surprised how many unversioned files creep into a CI build when all you're relying on is the build script's "clean" task
> -----Original Message-----
> From: David Weintraub [mailto:qazwart_at_gmail.com]
> Sent: 12 March 2012 16:33
> To: Nico Kadel-Garcia
> Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; Simon Dean;
> users_at_subversion.apache.org
> Subject: Re: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
>
> 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
-----------------------------------------------------------------------------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information, or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Although this e-mail and any attachments are believed to be free of any virus, or other defect which might affect any computer or system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Moneysupermarket.com Financial Group Limited for any loss or damage from receipt or use thereof.
The views expressed are of the individual, and do not necessarily reflect the views of Moneysupermarket.com Financial Group Limited.
Moneysupermarket.com Limited is an appointed representative of Moneysupermarket.com Financial Group Limited, which is authorised and regulated by the Financial Services Authority (FSA FRN 303190).
Moneysupermarket.com Financial Group Limited, registered in England No. 3157344.
Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. Telephone 01244 665700.
Received on 2012-03-12 18:08:05 CET