Svn – Installing TortoiseSVN for specific users on Citrix XenApp

citrixsvntortoisesvnxenappxendesktop

The question here is straight-forward: how do I install TortoiseSVN on Citrix XenApp so that only specific people can see/use the program, without a 2nd group of people even seeing that the program exists?

Under Citrix's old MetaframeXP product, there was an option to install applications on a per-user basis. Normally, using the system's "Install Program" feature from the Applications control panel resulted in the Citrix server entering a specific mode that registered the installed program for all users. If you didn't use this mode, the program would install for the user account that was performing the installation only. This allowed the administrator to set up programs that could be used only by specific users; other users would not see the program, nor would they have the appropriate registry entries. Yes, you could see the installed files, but it was pretty much non-functional for other users.

With the XenApp environment, this is supposedly no longer an option. As it has been explained to me by the admin(s) heading up systems maintenance for our Citrix installs, programs installed in XenAppDesktop and used as a published desktop (not published app) will be visible to everyone on the server. And here lies the issue: TortoiseSVN installs a shell extension, and because of that, the extension will be visible to all users, not just developers or admins that need access to it. Our non-technical end-users will simply go bananas when they start calling about "some weird thing showing up when I click to look at files".

We are running XenApp on WS2003R2/64.


Before answering with something other than "this is how to do it with what you've got", please consider the following as well:

Yes, this is a business installation, which means licenses, etc.

No, switching off of Subversion is not an answer at this time. Yes, I am fully aware of the popularity of Git/Mercuriual/${Insert-Favorite-DVCS-Here} and how they are all a bazillion times better, will make my laundry whites whiter, save kittens and puppies, etc. etc. That is beside the point; the effort of migrating to a different system just to get around this issue is several times higher than just addressing the issue. So, no, switching the back-end is not an acceptable answer.

No, adding yet another (expensive) Citrix server just for developers is also out of the question. I don't set budgets, and I don't get to determine what money is spent where. Telling me to "Just add another server" is akin to me going to some country's starving population and saying "just eat more food". The resources available are fixed, so it's not an option.

Yes, having another cheap/free remote access solution that provides a Windows desktop as a hosted service may be considered. However, the cheapest solution I've found is still in the four-digit range, which is not something that I can talk to management about approving. Short version: if the cost of setting up a secondary remote Windows desktop exceeds $25/seat for 7 developers then it's not viable (not including of course the licensing fees for Windows…) It would have to be a really compelling solution for management to consider this, but if it looks good, I'll try to make a case for it.

Best Answer

Two options come to mind:

  1. Set permissions on the directories and registry keys created during the TortoiseSVN install in such a way that users that should not see TortoiseSVN's shell extension do not have read access.

  2. Replace the physical XenApp installation with two virtual XenApp servers on the existing hardware. Install TortoiseSVN on only one of them.