BUG: Working Folder for Subproject Not Inherited from Parent

[$/Project1]
   Dir(PC) = c:\Project1

   ;Setting the working folder then deleting it from the GUI leaves the Dir
   variable, but the value will be blank.
   [$/Project1/Sub1]
   Dir(PC) =

   [$/Project1/Sub2]
   Dir(PC) = c:\temp
				

MORE INFORMATION

When setting the working folder of a top-level Visual SourceSafe (VSS) project, by default all subprojects assume a working folder based on a mirror of the project's directory structure on disk.

For example, suppose you have the following project structure in VSS:

$/Project1

             /Sub1
                  /SubofSub1
             /Sub2
				

Setting the working folder for $/Project1 to C:\Project1 implicitly sets the working folder of the subprojects to C:\Project1\Sub1, C:\Project1\Sub1\SubofSub1 and C:\Project1\Sub1\Sub2, respectively.

If you explicitly set the working folder of a subproject, you are essentially telling VSS, "Don't assume a working folder for this subproject", which in some cases may be desired. VSS accomplishes this by adding the Dir variable under the subproject's header section in the Ss.ini file.

Steps to Reproduce Problem

1. Create a project structure in VSS similar to the one above.
2. Explicitly set the working folder for the subproject /Sub1 by highlighting it and choosing Set Working Folder from the File menu.
3. Choose a folder and click OK.
4. Now open the Set Working Folder dialog box again, and delete the chosen folder setting from the Name text box, then click OK. These steps remove the working folder for /Sub1 and create the Dir()=<blank> in your Ss.ini file after you exit the VSS explorer.
5. Now set the working folder for $/Project1. $/Project1/Sub1, or any of its subprojects, will not have its working folder set, but $/Project1 and $/Project1/Sub2 will have the working folder set.

NOTE: To maintain the default behavior of working folder inheritance, avoid setting the working folders for subprojects explicitly.