Folders

The project or server administrator usually creates projects and project views. If you are a typical user, you routinely open a particular project view and manage your folders and their contents, such as files and change requests. Managing application folders is very similar to managing a project. You can create folders, delete folders, and modify their properties—if you have the correct access rights.

Folder Hierarchy

When you create projects, you typically select locations on your workstations as the working folders for those projects. The working folder designated for a project also becomes the working folder for the project’s root view and for the root folder in that view’s folder hierarchy.

StarTeam treats folders as both containers and items. You can group items within a project view by placing them into folders. For example, a folder named Source Code can contain source code files and requested changes to those files. You can create folders automatically when you create a project, or add folders after you create the project. Project or server administrators (or team leads – this all depends on your organization) usually create projects, but anyone can create projects if they have the correct access rights. See your server administrator if you have questions regarding the access rights assigned to you.

When you create a project, StarTeam automatically creates the parent or root folder for that project at the same time. It is actually the root folder of the project’s root (or initial) view. The project, view, and this root folder initially have the same name (although those names can be changed).

Usually, the user who creates a project sets up a hierarchy of folders on a workstation before creating the project. The user designates the root folder of that hierarchy as the project’s working folder. Then the application can automatically create an application folder for each of the child folders in the hierarchy. The child folder becomes the application folder’s working folder.

If child application folders are created at the time the project is created, then:

  • The application folders’ working folders were part of an existing hierarchy on the project creator’s workstation.
  • Their names are the same as the names of their working folders, but they can be changed later.
  • Their working folders remain hierarchically connected to the root folder’s working folder. That is, if you change the path to the root folder’s working folder, you also change the path to this folder (unless you manually set an absolute path for these working folders). In other words, the application stores a relative path to each child folder.

One of the most important properties to notice about your folder is its working folder. You will need to know where on your workstation the application will copy file revisions that you check out so that you locate those revisions as needed for modifications. A number of other operations can be performed on folders, such as moving a folder or changing its branching behavior.

A working folder is a property of the folder and represents the actual location on your workstation where StarTeam saves files that you check-out. Despite the fact that these are both called folders, the working folder and the folder are not identical. Their differentiating characteristics include:

  • The path to the working folder can be totally different from the path within the application to the application folder.
  • An application folder is an object controlled from within the application. The data associated with this folder is stored in the database that stores all the project data.
  • A working folder is an object controlled by your operating system. It stores files that are checked out from the application.

A project, its root view, and the root folder of the root view all have the same working folder. For additional views, each view and its root folder have the same working folder.

The working folder for the view/root folder always has an absolute path (starting with the drive letter and specifically naming the folders at subsequent levels until you reach the working folder itself).

If you look at the properties for the root folder, you will see that the working folder is the same. However, it is displayed in the Complete Working Folder Path display box instead of the Default field. Since you can only change the working folder at the view level, all of the fields for the root folder’s working folder are always disabled.

For the child folders that were created at the same time as the project, the application stores the path to each working folder as a relative path.