It’s amazing how many times I’m asked about how you can collaborate on sub-projects or individual features with other developers without affecting the rest of the development team.  As a matter of fact, this came up the other day, which is why I thought it would make a good post.

There are several ways that teams can collaborate in AccuRev, and depending upon what the situation is, would choose different methods.  I describe two simple scenarios where 2 developers are working on a few files together and another where several developers are teamed together to work on a sub-project.

Scenario 1: Two developers are working on the same foo.c file and must complete the work before it can be merged with the rest of the project (ie. promoted).

The great thing about private workspaces is that developers have a place where they can commit their code without impacting the rest of the team.  The code *is* placed on the server, but still remains private to the developer.  Meaning, other developers who update their workspaces will not propagate those changes into their private workspaces.

However, since the code *is* on the server, another developer can explicitly pull that version into their workspace using the “send to workspace” command (aka. “co”).  The developer can make changes and keep the file to place the new version on the server, again stored in the private workspace.  This exchange continues until the work is completed and the file can be promoted to be shared with the rest of the team.

This is typically a good method to use for collaborating on just a few files, but what if you had an entire sub-project to share with many developers.

Scenario 2: Many developers working on entire sub-project which must be completed with testing before merging with the rest of the project.

This scenario is the “bread and butter” of what AccuRev and the stream based architecture is all about.

To set this up, you simply create a stream for the sub-project from the main project stream.  The sub-project development team creates workspaces off the sub-project stream while the rest of the development group is based upon the main project stream.

With inheritance, any changes made by the main project team is automatically inherited by the sub-project team so they [sub-project team] are continuously integrating with the main development effort.  The main project team is completely unaffected by the changes made by the sub-project team.  The sub-project team can also control what changes are inherited into their stream by setting a time basis on their stream.  The time basis will only allow the changes to flow into their stream up to the time set.

Eventhough I described this scenario as a method for larger groups, it can also be used for the simple case of 2 developers working on the same file.   Streams are so architectually light weight, that they can be created and removed in a matter of seconds.

 I hope this little tip helped for those looking to collaborate.