Of high importance is the structure of the respository in the Version Control System.
Both times I have been aiming for :
- ability for the developer to have multiple local working copies, and flexibility to locate their working copies in any folder on any drive.
- consistency across all developer machines
- ability to use and version control the files of any tool, and have those files be usable by other developers
- all necessary files under a single root.
Currently we are working with Subversion and TortoiseSVN, NAnt and CruiseControl.Net. Our code is in C# and C++.
The above has been achieved and working well using the Windows SUBST command to create a drive R: (for repository) under which all files are stored. Under this the folders are projects, tools, thirdparty, total (for the build) and rnd (for Research aNd Development).
When I upgraded to V1.4 of Tortoise however, the icons indicating file status (up to date, modified, added etc) began behaving strangely. On reading the Tortoise list (subject: "TortoiseSVN Bug with overlay icons on network drives") I see from Stefan Küng
> The status cache can't work reliably with SUBST drives! The cache worksLater
> by monitoring the filesystem for changes. Every change fires an event
> which the cache catches and acts accordingly. But if you have a SUBST
> drive, then even though you have two (or more) paths that point to the
> very same location on the filesystem, only one event is fired. Which
> means you will *always* get unpredictable result
Just a suggestion, but have you tried loopback mounting a network drive?Hey! I never thought of that !
Share the folder you create a subst of as a private share (end the share
name with $), read/write only by the user (or read/write only by the
machine, if you prefer), and mount that network drive as another drive
letter. I used to use subst too, but found that too many programs broke
with it. Never had a problem with the loopback network drive.
So I tried it, and hit the next problem : .Net's Code Access Security. Any mounted network share (even from your own machine) is treated as of the "Local Intranet" security zone, which is by default of "medium trust". This isn't good enough for some things, such as NAnt and Visual Studio.
After further digging, and thanks to the references below I now have my local share R: drive fully trusted, without affecting the rest of the local intranet zone.
Here's the answer :
- Share the folder you want to mount
- Map a drive letter to it.
- execute the following lines in a dos shell or batch file :
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CasPol.exe -q -pp off -machine -addgroup 1 -url file://R:/* FullTrust -name "Drive_R" -description "R: Local Network Drive"each line adds the policy for a different version of .Net. Each version's security operates independently.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -q -pp off -machine -addgroup 1 -url file://R:/* FullTrust -name "Drive_R" -description "R: Local Network Drive"
Now it just needs a batch file to be able to do :
MapDrive R: D:\Repos\DriveR
Maybe another day...
- Using CasPol to Fully Trust a Share
- How Do I...Script Security Policy Changes?
- Getting CLR Security Right - Seeing Double