Workspace Groups

The Version Browser makes use of workspace groups to simplify the display of element versions that have been modified and promoted sequentially from multiple workspaces. Note that workspace groups do not exist or have any meaning anywhere other than the Version Browser.

Assume the following common sequence of events:

1.	User1 creates and promotes a new file called file1.c in workspace WS1.

2.	User2 updates her workspace (WS2), modifies file1.c, and promotes it.

3.	User1 updates WS1, makes more changes to file1.c, and promotes it again.

4.	User2 updates WS2 and makes yet more changes to file1.c.

5.	This time, User3 also makes changes in WS3 to the version of file1.c last promoted by User1. (User2 and User3 are making changes to them same file in parallel.)

6.	User3 promotes his changes from WS3, causing an overlap conflict for User2.

7.	User2 merges in User3’s changes so she can promote her file.

8.	User4 then updates his workspace (WS4) with User2’s merged version, and makes his own changes and promotes. After a review, he makes some further changes and promotes again.

In a traditional version graph, the above scenario could be expressed as shown in the following figure:

In earlier versions of the AccuRev Version Browser, each workspace would have generated a new row in the graphical view, along with ancestry lines connecting the versions. In large installations with many workspaces and many changes, the Version Browser display could quickly become unmanageable.

As of AccuRev 6.0, the Version Browser provides a workspace group which represents all of the workspaces that fall along a common line in the version graph:

This makes the version browser much easier to navigate and understand. To see which workspaces belong to which workspace groups, view the Streams & Workspaces tab in the lower pane and check the “Groups” column.