When you run Get on a folder (aka project) in VSS Explorer, you’re presented with these options:
(if you don’t get this dialog, try holding Shift)
Most of the options are obvious, but not “build tree” — at least not to me. The online help explains it thusly:
Projects only. Overrides the working folders for the subprojects in a recursive operation and builds a project tree on your local computer that mirrors the database project organization. Working folder settings for individual subprojects are ignored. This option is available only when you select the Recursive check box.
Decent explanation — but if frequent customer inquiries are any guide, it would really benefit from a concrete example. Luckily, Patrick McCormick gave a great one last time the question came up. I’ve dressed it up with screenshots for added clarity. Let’s start with a simple database.
If I run Get on the root ( $/ ), “build tree” will ensure that the file structure created on disk looks the same.
Ordinarily, the “build tree” checkbox is not necessary to get this result. However, it’s possible to set explicit working folders in SourceSafe. Working folders might point to completely different locations on disk. If you previously worked with our two WindowsApplications separately it’s not likely they map to sibling folders (unless you were very careful). Moreover, if you normally use the Visual Studio IDE, you would never notice because VS uses its own “bindings,” not the mappings from VSS Explorer. Thus, you might have inadvertently set up mappings such as
$/WindowsApplication1 -> c:\users\richard\documents\WindowsApplication1
$/WindowsApplication2 -> d:\vss\WindowsApplication2
So long as you’re working with these projects independently, that’s no big deal. But if you’re fetching both of them as part of the same Get operation, there’s a good chance you intend to build them together, which means their relative path becomes important. That’s the scenario “build tree” intends to enable.