Scenarios for Mapping Multiple Repositories to a Single Stream

There are two common reasons for mapping two different Git repositories to the same AccuRev stream:

• Project-based.
• Security-based.

Project-Based

Figure 1. Project-based (same stream, different mount points)

In this case, you might have two different parts of a product in two different directory structures in the same stream, such as a GUI development tree and a database development tree. In the Git environment, you could have the GUI work being done in one repository and the database work being done in another.

By mapping the branches in these repositories to the correct mount points in the same stream, you can keep the work separate. (Keeping the branch names consistent across repos will be helpful if you need to make branch-mapping changes en masse using the children-of option in the SSH config-branch CLI command.)

Security-based

Figure 2. Security-based (same stream, same mount point, different service account)

In this case, you could have two different sets of users with different access privileges accessing the same files. Privileged Git developers in corporate headquarters could have one repo mapped to the mount point with one service account having “lenient” AccuRev ACLs. Less privileged off-shore contract developers could have a different repo mapped to the same mount point with a different service account having much more restrictive AccuRev ACLs. See Configuring for Security for more information about ACLs and security.

Also, by mapping branches from different repos to a single AccuRev stream, you can automate the process of updating repos with changes: when a change gets pushed to a repo that is mapped to an AccuRev stream, that change gets propagated to all other branches that are mapped to that stream (assuming that the AccuRev ACLs allow a repo to “see” the changed file).