Flow target is the target area where the delivered changes flow into. The flow target for repository workspaces can be a stream or another workspace. Flow target can be modified from the repository workspace editor.

Once we load the code, we can start working on the code changes and can submit the change lists back to the flow targets. Check-in copies work from our local workspace to our repository workspace. Our changes or work items remain private and local to the workspace until we decide to deliver it to a team flow target such as a shared stream. We can also replace the contents of the components with other repository workspace components or different baselines of that component.

The previous picture gives an overview of the complete process from check-in to load steps. Let us see a scenario where the user skrishna checks-in and another user fgerhardt loads the changes.

At times, we want to work on a piece of functionality and do not want to deliver the changes to a stream. This could be because we are experimenting with a piece of functionality or this is a quick customer demo. In such cases, we can create a new repository workspace where the artifact changes in the component will not flow to any target.

A repository workspace without a flow target can be identified with the help of visual clues as seen in the previous screenshot. In the Pending Changes view, we would notice that while other repositories have the flow targets represented by "<->", the repository without a follow target misses this representation.

Remember that when the repository workspace does not have a flow target, we could still do the changes on the component and check in. However, we do not have the option to deliver the changes as there is no associated stream as a flow target. Thus, we can take full advantage of the source control features except that we cannot flow to a target.

Whether or not the repository workspace has a flow target, every repository has an owner who manages the repository visibility, components, and flow targets. It is a rather natural scenario in software development that a piece of work is created by one team member and later edited by another. In this case, the Rational Team Concert client enables us to change the ownership of the repository workspace so that other team members can continue the work as an owner.

As an administrator, we want to know the number of repository workspaces for a project or average repository workspaces for a team member. As a team member, we want to search for one of many workspaces that we own. Rational Team Concert's client provides an easy way to search for the available workspace repositories and ownerships. On the Team Artifacts view, select My Repository Workspaces and select Search for Repository Workspaces on the context menu. This will show a complete list of the available workspace repositories and the associated owner.

A snapshot is a repository object that includes exactly one baseline for each component in a repository workspace. (A baseline is a repository object that records the state of a component at a specific time. Every component has at least one baseline, which was created when the component was created.) Snapshots are useful for capturing the state of a workspace, and are typically used to record important workspace configurations so that they can be recreated. A workspace snapshot gives a collection of component baselines at an exact point in time.

A snapshot is created on a repository workspace with all the available components and, if needed, the snapshot can be promoted onto a stream. When we create a snapshot, the process will automatically create a baseline for the components that do not have one. Snapshots are also created by the Rational Build Engine so that we exactly know which snapshot is used to do a build. The snapshot and baselines created by the build are private to the build workspace. If we want to make them official, we can promote them to a stream.

We can create a snapshot by selecting the appropriate repository workspace and on the context menu select New | Snapshot. Enter the required information and select the list of components that participate in the snapshot. Finally, click on OK to create a new snapshot as shown next:

The creation of a snapshot also creates a new baseline for the available components in the workspace. In the repository workspace of the BookManager project, we can notice that the component version numbers increase by one. Also, in the Pending Changes view, the new versions of the components are ready to be delivered to the stream as shown in the following screenshot:

It is a common scenario that once software is released, we want to work on a specific baseline or snapshot of the component to fix issues or bugs. Without a baseline, it could become very painful to find the exact code base and then discard or back up the current changes manually. With Rational Team Concert, we can easily replace the repository workspace contents with components from another baseline.

Many times projects generate files that do not need to be under the source control. In such cases, Rational Team Concert's client provides the capability to identify and make the files ignored by the source control. Ignored resources are not checked in by the source control.

The list of resources to be ignored by Rational Team Concert source control is kept in a file named .jazzignore. There is typically a .jazzignore file in the project root folder. Files and folders whose names appear in .jazzignore will not be checked in, and therefore, cannot become part of a change set. While ignoring a resource, we can choose to ignore them project-wide or in a specific folder. By default, Rational Team Concert source control ignores two types of files—resources ending with a .class extension, and the bin directory of an Eclipse workspace. To add additional resources to the ignore list, follow the next steps:

A .jazzignore file is treated like any other file under Rational Team Concert source control. When we modify it and want other team members to take advantage of this, we must check it to copy it to our repository workspace.

The following is a sample .jazzignore file that specifies the .class files as a pattern to ignore for the BookManager project component:

### Jazz Ignore 0
# Default value for core.ignore.recursive is *.class
#  Changing this value changes check-in behavior for the entire project. 
#
# Default value for core.ignore is bin
#  Changing this value changes check-in behavior for the localdirectory.
#
# Ignore properties should contain a space separated list offilename patterns.
# Each pattern is case sensitive and surrounded by braces('{' and '}'). 
# "*" matches zero or more characters, and "?" matches singlecharacters. 
#
#   e.g: {*.sh} {\.*}    ignores shell scripts and hidden files

# NOTE: modifying ignore files will not change the ignore status of derived 
# resources.

core.ignore.recursive= \
  {*.class} 

core.ignore= \
  {bin} \
  {build} \
  {dist}

This component has a build file that generates the class files, compiles, and makes it distributable in local directories. Therefore, the different files bin, build, and dist are added as patterns so that the build-generated directories are ignored. This is an extremely useful feature for the team that everyone uses a single configuration and reduces the erroneous check-ins.

Rational Team Concert provides an efficient way to "lock" and "unlock" the project artifacts depending on a project's need. Many times, it is necessary to lock the resource till the change is done and delivered to the stream. In instances when we are fixing a critical customer bug or a document file that is difficult to merge, we need an explicit lock. This ensures that our version of change is always delivered without conflicts from other team members.

To lock a resource from the Rational Team Concert client, select the resource, and from the context menu, select Team | Lock.

Before a resource is locked, we are asked to select the streams that this resource will remain locked till the change set is delivered as shown in the previous screenshot. Depending on the requirement, one can select multiple streams to lock the resource while not locking the same resource in some other streams.

Soon after locking a resource, all the users will be able to see that this resource is locked by a specific user on a stream. The Rational Team Concert client UI indicates the lock by a visible marker that reads like Locked by <USERNAME> in <STREAM>.