Consider that we want to store four distinct exported versions of the CadStar project on our computer. No problem! We simply use four distinct physical trees. E.g.
$1 = c:/dev/CadStar/V1.0
$2 = c:/dev/CadStar/V1.1
$3 = c:/dev/CadStar/V1.2
$4 = e:/dev/CadStar/V2.0
These are physical paths to physical trees and there can be any number of conventions for organising these directories on the hard-disk or in a given repository. Some users for example may simply use a large flat list under a single directory. Other users will want to organise the physical trees in a structure using directories. It is of course permissible (and in fact recommended) for this structure to be recorded in a source code repository, i.e. so development teams share the same structure).
A virtual tree references a given physical tree using a local physical path. It follows that any number of distinct virtual trees can reference the same physical tree. In other words the virtual tree idea promotes sharing. For example, V1.2 of CadStar only needs to be stored once on a given development machine, and yet it can be used by many different build environments.
Often a given physical tree holds some exported projects. The nice feature is that the full directory structures are always recorded relative to $, which eliminates the need for the developer to manually specify where physical trees need to be “mounted”. This largely automates the process of bringing a wide range and disparate set of third party software libraries together to form a build environment. All the user needs to do is specify a virtual tree - i.e. an ordered sequence of local paths to physical trees.
Xcpp project and workspace files are written in a way that is completely independent of versioning concerns. i.e. we never see anything like a version number in either type of file. This helps to ensure that different developers can build the same project in different ways, and not be “fighting” with each other when editing .xcpj or .xcws files.
A Xcpp workspace can define what projects to package, but doesn’t try to stipulate what versions of what projects to package. Version information is instead managed by the developer when specifying the virtual tree to be used for a given build environment.