The problem with subversion is, that almost all new client versions introduce a new working copy format. Although there is an svn upgrade command to migrate the working copy to the new version, there is no way back. (Except deleting the working copy and checking it out again with the old version of subversion) Despite this is no problem in a local environment with only one version of subversion in action, this is a real pain in shared environments. Consider a network share with some working copies in it. Whenever your local subversion version is newer than the one of the host, you could not access it. You do not want to upgrade the working copy on a host! Except you like angry colleagues. Of course most of the time you check out the working copy locally, but still you wanna be able to check the status of a working copy without changing the working copy format or without reemerging an older version of subversion locally. This becomes even more painful in the following scenario: (my personal problem) Consider a software product, which consists of three parts: 1. The operating system abstraction layer and all needed open source libraries in a Gentoo Prefix called toolsbox. 2. All kind of build, configuration, vcs scripts in an administration repository. 3. The Buisness code of the product in a source repository. In the product source we tag a new release once a year. The administration repository nearly stays the same throughout two years. And the toolsbox stays compatible through many years, so that the first release of the product which uses the toolsbox can still upgrade to the newest version without changing anything in it. Now we upgrade the toolsbox to a new snapshot so we got a new subversion version. We had a few issues with the package upgrades, there the working copy format becomming incompatible is a big deal. There are many developers working on different versions of the product source, all of them using the same administration working copy. Now the head version of the product using the newest toolsbox (subversion-1.8) is incompatible to all released products using the previous toolsbox shipped with subversion-1.6. With slotted subversion it would be possible to access the shared administration working copy fom the current product without making it unusable for the previously released products. The deluxe version would automatically detect the subversion version to be used with an existing working copy, but at first an "eselect subversion" would be of great help to us. Reproducible: Always Steps to Reproduce: 1.svn-1.6: svn co <something> 2.svn-1.7/8: cd <something>, svn st/up -> need svn upgrade 3.svn-1.6: cd <something>, svn st/up-> not possible anymore Actual Results: working copy unusable for all older subversion clients Expected Results: Select the subversion version to be used through eselect, so that instead of svn upgrade -> eselect subversion set <the older version> is possible.
We currently dont have the manpower to even think about such a change and since subversion isnt built with slotting in mind, this would require a good amount of work to even do. We keep the older versions around for as long as possible, so if you for some reason would like to stay with the 1.7 series, it is still in the tree and maintained, so you can delay your upgrade to the 1.8 series until your server has done so. So sorry, unless you can step up as additional ebuild maintainer and can provide slotted versions, there is no chance for this to happen anytime in the near future.
Alright. I give it a shot. If I see a chance in realizing it, I will report back.
