References Created by Moving Objects

When you move a folder or item from one location to another within the same view, StarTeam deletes the object at the old location and reinstates it at the new location. However, there can be side effects in that view’s parents and children if any of the views are floating. This is because the copy at the old location is not deleted except in the current view. The parent and child views may end up with two references (one to the old location and one to the new location) instead of one to the new location.

Reference Hierarchy Examples

Suppose you move the file named timeout.doc from the Marketing Documentation folder to the Timeout folder in a given view that has no branching child views.

The following two examples show the references for this file before and after the move. The number of references is the same; only the path to the file has changed. The file has been deleted from its original location and added to its new location.

Before the move: Big Product::Big Product::Big Product\Marketing Documents::timeout.doc, 1.0

After the move: Big Product::Big Product::Big Product\Source Code\Timeout::timeout.doc, 1.0

However, suppose this view has a child view that was created without cutting off the connection to the parent (in other words the child view is branched and floating). In the child view, if the moved file has not yet branched, it is not deleted from its old location because you might really still want it here. However, it is added to the new location because it is perceived as a change to the parent that should be reflected in the child.

Notice that the file has only one reference in the parent but that it has two in the child view.

  • Big Product::Big Product::Big Product\Source Code\Timeout::timeout.doc, 1.0
  • Big Product::Big Product\branched floating::Big Product\Marketing Documents::timeout.doc, 1.0
  • Big Product::Big Product\branched floating::Big Product\Source Code\Timeout::timeout.doc, 1.0

Some users sort items using folders. For example, they decide to create a series of folders in a view to classify change requests by criteria such as:

  • Will definitely make the next release
  • Are under consideration for the next release (time permitting)

These change requests are usually moved from the root folder to one of the sorting folders, or later rearranged and moved from one sorting folder to another. This is a convenience in the current view, but it can cause multiple references in a parent or child view. If the view hierarchy is deep, the current view’s parents, grandparents, children, grandchildren, and so on may be affected. Users who use such systems usually create child views that do not float.

Back to top

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. Suppose all the views except the root view branch and float. At its new location, the folder or item you move can float:

  • Up the view hierarchy from the recipient view to the root view
  • Down to all the children, grandchildren, and so on of the recipient view
  • From the parents, grandparents, and so on of the recipient view to all of their other children

A move operation results in one fewer reference to the moved folder or item in the view from which it was moved, and one more reference to it in the recipient view.

The following example shows that a file named move within parent view was moved from one location in the root view to another location in that same view (which is why there is only one reference to it in that view). Originally, the file was referenced in five views. The move caused a new reference in all the child views of the root folder, giving each of them two references to the moved file (one reference in its original location and one in its new location).

  • Big Product::Big Product::Big Product\Source Code::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch all floating::Big Product::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating::Big Product::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating\branch none floating2::Big Product::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating\branch none floating2\branch none floating3::Big Product::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch all floating::Big Product\Source Code::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating::Big Product\Source Code::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating\branch none floating2::Big Product\Source Code::moved within parent view.doc, 1.0
  • Big Product::Big Product\branch none floating\branch none floating2\branch none floating3::Big Product\Source Code::moved within parent view.doc, 1.0

Back to top