Share this page
References Created by Adding Items to Views
The addition of a new folder or item to a parent or child view can result in one or two references, depending on the relationship between the two views.
If the child view is a branching, floating view, StarTeam creates a reference in each view when a new folder or item is added to the parent.
If the child view is a branching, floating view created using the Branch None option, StarTeam creates a reference in each view when a new folder or item is added to the child.
Floating Down in the View Hierarchy
When a view has a branching child view (whether created with the Branch None or Branch All option) and the child view is floating, any folder or item added to the parent view becomes visible in both views. The history of the folder or item indicates the view in which the object was created, and the reference hierarchy displays the reference that identifies the parent view as the parent reference.
For example, if a file you add a file to the parent view, its history in either view shows the name of the parent view—until the file branches in the child view.
The following table shows the history in the parent view for a file that was added to the parent view and floated downwards.
Tip: You can review historical item information using the History tab in the client.
| View | Revision | Branch Revision |
|---|---|---|
| Big Product | 2 | 1.1 |
| Big Product | 1 | 1.0 |
The following table shows the history in the child view for a file that was added to the parent view and floated downwards. The history of the file displays the name of the view from which the file was originally added to the application, until the file branches. Then it displays the name of the view in which the file branched.
| View | Revision | Branch Revision |
|---|---|---|
| branch none floating | 3 | 1.1.1.0 |
| Big Product | 2 | 1.1 |
| Big Product | 1 | 1.0 |
If you were to display the References tab for this file (marketshares.doc) after it has branched in the child view, you would see the following information:
-
Big Product::Big Product::Big Product\Marketing Documents::marketshares.doc, 1.1
-
Big Product::Big Product\branch none floating::Big Product\Marketing Documents::marketshares.doc, 1.1.1.0
Notice that the history clearly shows the parent view as Big Product before the file branches. The history and references for folders and items added to the parent view are similar to those for folders and items that were in the parent view at the time the child view was created.
Note: The name of the views in these examples makes the information easier to understand. You would probably never name a view parent or any other of the names shown these examples.
Floating Up in the View Hierarchy
When a view has a branching child view (created with the Branch None option) and the child view is floating, any folder or item added to the child view becomes visible in both views. This is not true of branching, floating child views that were created using the Branch All option.
The history of the folder or item indicates the view in which the object was created, but the reference hierarchy always displays the reference that identifies the parent view as the parent reference.
The following table shows the history in the parent view for a file that was added to a child view and floated upwards. Notice that, even though this is the history in the parent view, the history displays the name of the view from which the file was originally added to the application.
| View | Revision | Branch Revision |
|---|---|---|
| branch none floating | 3 | 1.2 |
| branch none floating | 2 | 1.1 |
| branch none floating | 1 | 1.0 |
The following table shows the history in the child view for a file that was added to the child view and floated upwards. The history of the file displays the name of the view from which the file was originally added to the application—until the file branches. Then it displays the name of the view in which the file branched. In this case, those two views just happen to be the same view.
| View | Revision | Branch Revision |
|---|---|---|
| branch none floating | 3 | 1.1.1.0 |
| branch none floating | 2 | 1.1 |
| branch none floating | 1 | 1.0 |
When you view the reference hierarchy for a file that floats upwards, you cannot tell that the file was added to the application from the branching child view, and you must investigate the history (using the History tab) of the file to determine where the file originated. For example, the Reference tab would contain the following reference hierarchy for the slant.doc file that floated upwards:
-
style="width: 30px; height: 13px;" />Big Product::Big Product::Big Product\Source Code\Timeout::slant.doc, 1.2
-
style="width: 16px; height: 13px;" />Big Product::Big Product\branch none floating::Big Product\Source Code\Timeout::slant.doc, 1.1.1.0
Floating Up and Down in the View Hierarchy
If the view hierarchy is deep (the root view has grandchildren, great-grandchildren, and so on), the use of branching, floating views can cause a great deal of confusion. For example, suppose you add a file to a grandchild of the root view. Further, suppose that this grandchild view was created using the Branch None option and that its parent (a child of the root view) was created using the Branch None option. The file you add can float up to the parent and grandparent of the current view from which it will, in turn, float back down to the current view. This results in:
- One reference to the file in the current view
- One reference to the file in the parent of the current view (the result of floating up from the current view)
- One reference to the file in the root view (the result of floating up from the parent of the current view)
More references are created if the current view has floating children, grandchildren, and so on. Still more are created if the root view or parent view have other floating children besides the ones mentioned above.
