Not having contributed to SVN before, I don't really know how the SVN client(s) are implemented. How much of the code in the various Windows and Linux SVN command line clients (e.g. CollabNet's Windows command line client, SlikSVN's Windows command line client, TortoiseSVN's svn.exe etc) comes from the codebase that Apache now manage and how much is unique to each client?
Is it the Subversion API that provides the bulk of their various clients' functionality? What keeps the command arguments etc. of the various clients the same? Thanks Simon > -----Original Message----- > From: Simon Dean > Sent: 12 March 2012 17:05 > To: 'David Weintraub'; Nico Kadel-Garcia > Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; users@subversion.apache.org > Subject: RE: Feature request - SVN command to clean a working copy of all > unversioned and ignored files and directories > > 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:qazw...@gmail.com] > > Sent: 12 March 2012 16:33 > > To: Nico Kadel-Garcia > > Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; Simon Dean; > > users@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 > > qazw...@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.
