The .ROOT Folder and "Unified Root"

  • Article

In a recent post, Chris
Flaat offers some good advice for developers who include "linked files" in
their source-controlled projects. Linked files, which are also called "reference
files" in some language projects, are files that do not occupy the
same drive or directory on disk as the project file itself. Chris explains that adding linked
files to your source-controlled projects can complicate the management
of projects in Visual Studio .NET. Somewhere in this explanation, he refers to
the concept of a "unified root". 

A unified root is the folder in an hierarchical directory
beneath which all the files referenced by a [source-controlled] solution or
project can be found. Chris
Flaat defines it as "the closest common parent to all the files in the
project" (which is a great definition except that I would replace
the word project with 'solution'). C:\ is the unified root of a solution
whose solution file (*.sln) lives at c:\solution1.sln and whose one project
lives in c:\projects\ProjA.csproj. So what is the unified root of a solution
whose .sln file lives in C:\Solution1 and whose only project lives in
D:\ProjA?  No existe. Since C:\ and D:\ are inherently parentless
directories, Solution1 is without a unified root.

In Visual Studio .NET 2002 (v1), such "Unified Rootless" solutions occasioned
a number of hard-to-explain source control foibles, especially in the context of
multi-project solutions. The end user experience was good, but not
excellent.  Two of the most noticeable foibles were seemingly redundant SCC
prompts and a 'Yes All' button that did not always work as expected when
performing batch SCC operations.

Recently, several VS.NET 2003 (v2) customers have inquired about a
"mysterious" new folder (SolutionName.root) that
keeps showing up in their source control databases when adding
solutions to SCC via Visual Studio .NET 2003 (aka "Everett"). It's not a
Microsoft conspiracy, I promise :-). It's a feature.

To elevate the user experience from good to excellent, the SCC feature
team implemented a simple and elegant fix in VS .NET 2003 that creates an
empty .ROOT folder in the source control database and then adds child
folders for the solution and projects thereunder. Essentially, the empty .ROOT
folder maps to an as yet undefined and
uncalculated   [Blank**]-Unifed Root, with the
following benefits (partial list):

  • Fewer SCC Prompts--now, you can create a solution, populate it with three
    new projects, add it to source control, and experience the magic of...
    nothing.
  • Parallel File Organization--now, if your solution and projects all reside on a
    single drive, their source control "view" (hierarchical organization) is
    practically the same as their logical "view" in Solution Explorer*. This
    organizational parallelism has many benefits, especially in the area of
    advanced source control operations such as binding-unbinding and
    sharing-branching-merging.
  • Supports the Concept of a [Blank**]-Unified Root--Now, if
    you add a project to a source-controlled solution whose files reside
    on a different drive or computer, perhaps a Web project by UNC path, the new
    project is added to the repository under the .ROOT project as a peer to the
    folder containing the solution with which it is associated. Previously, this
    project would have been orphaned in the source control repository with nothing
    to inform you of the initimate relationship between it and the solution to
    which it belongs. In my opinion, this is one of the best reasons to leave this
    feature on...

I've heard a few academic complaints that the creation of the
SolutionName.root folder conflicts with the guidance offered in
our Team
Development Guide and the whitepaper
that Martyn Lovell and I wrote a while back. Technically, this is
true. In reality however, this feature change is perfectly congruent with that
advice and indeed, maintains an SCC folder structure that mirrors what
you see in Solution Explorer. Thus, I would more readily advise you to
revise your build process slightly than turn off the creation of the .ROOT
folder.  In fact, I plan to suggest that the BuildIt.net
tool (which is based on the Team Development Guide) be updated to
accomodate the .ROOT feature. Nevertheless, I'm not one to hold back
information unless I absolutely must. So here it is. You can turn off this
feature in VS.NET 2003 using the following procedure:

1.      Click Start, click
Run, type Regedit, and then click OK.

2.      Open
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl

3.      Select key DoNotCreateSolutionRootFolderInSourceControl, click Edit, and then
click Modify.

4.      In the Value
data box, change 0 to 1, and then click OK.

Caution   Mucking with your registry can do
irrevocable harm to your computer. Be careful.

Side Note  Recently, I've been thinking about how to
describe the relationship between a solution's logical organization in
Solution Explorer, the topology of the physical folders in which its
constituent files reside on disk, and the organization of the solution
in the source control repository. Any thoughts on what I should call these
conceptual "views" of a development project or solution.  Is
"workspace" too generic or overloaded?

As always, comments of all shapes, sizes, and languages are welcome.

*If, as I strongly recommend, you create a separate directory for the
solution when creating your first project or if you create a blank solution
and then add projects to it, your source control "view" and logical "view" in
Solution Explorer will be exactly the same as your solution's file
structure on disk.

**[Blank] is a type of overarching Unified Root that exists
above drives (eg, C: and D:) and mapped drives and is thus
"virtual" by nature. We've considered a few alternatives that have
since been ruled out, for one reason or another, including Virtual, Meta-, and
Über-. My favorite is Über ;-) . Super is still under
consideration, I think... Any other ideas?

This posting is
provided "AS IS" with no warranties, and confers no rights. Microsoft kann
für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine
Haftung übernehmen. Este mensaje se proporciona "como está" sin garantías
de ninguna clase, y no otorga ningún derecho.