A shared project is a project in the shared state
with members in the visible, shared,
or any static state.
When a project in the shared state, users can
make changes in the project. This behavior is unlike working or prep projects,
in which only a single user or users in a particular role are allowed
to make changes in the project.
Shared projects have several advantages, mostly related to multiple
users sharing a single project.
However, the same features that provide these benefits also impose
some limitations. You must understand the benefits and the limitations
so that you can determine whether shared projects are appropriate
for your team.
For more information about the dialog boxes and commands referenced
in this section, see Using Rational Synergy and Using dialog boxes and panes.
This topic contains the following sections:
Benefits of shared projects
Using
shared projects has the following benefits.
- Time savings
You do not have to check out a working version
of a large project (or multiple projects) to make minor changes. Unless
you are maintaining a working version of a shared project, you do
not need to perform maintenance or administrative operations. Instead,
you have immediate access to the project and its objects.
- Less training
Because all users can share the project, individual
users do not need to know how to administer the project, such as create,
update, sync, and set attributes. One user, such as the build manager,
can be responsible for administering the project.
- Shared development capability
The changes of other users are
available immediately. For example, if Bob and Ann are working in
the same shared project, Bob’s changes are available to Ann when the
changes are saved.
- Less disk space needed
Because all users are using a single
project, multiple copies of the work areas of the project are not
needed. This feature can save disk space.
Consider, however,
that the amount of disk space saved is minimal if you use link-based
work areas (with UNIX) or your
team has few uncontrolled files in the work area.
Limitations of shared projects
Shared
projects impose the following limitations.
- No insulation
No insulation is the most significant limitation
of shared projects. Several situations can occur in which you might
get unexpected behavior, particularly when you build products.
Building
in a shared project can have the effect of building in parallel. Users
can build shared products at any time, and the new products are configured
into the shared project automatically. Consequently, build results
can change without notice. For example, if one user changes a library
in a shared project, the change is included immediately. This change
can affect the subsequent builds of other users.
Incomplete
changes to shared files can cause unpredictable results. The files
are members of the project while they are being worked on, even if
they have not been debugged.
Finally, uncontrolled files in
the shared work area can affect build results. For example, uncontrolled
relocatable object files might be accessed by different users simultaneously,
or in an order that corrupts the files or changes the build results.
CAUTION:
The same feature that gives you immediate access to
changes also delivers (immediately and without notice) incompatible
changes of other users, incomplete changes, or errors.
If
you need an insulated project, you can check out and work in a working
version of the project. For more information, see Parallel development and shared projects.
- Limited file system security
Rational® Synergy
does not fully support file permissions for copy-based work areas
of shared projects. All users have permissions to rename, move, or
delete files in a copy-based work area. Also, they might be able to
change files for objects checked out to other users.
In copy-based
work areas, changes to work area files do not affect the controlled
files in the Rational Synergy
database. However, you must be careful to avoid syncing unwanted changes
from the work area back into the database.
Windows users can protect against unwanted
changes to the work area by using non-shared drives for their work
areas. However, this method prevents multiple users from sharing the
work area.
UNIX users
can protect against unwanted changes to the work area by making their
work areas link-based. Other users can change the links to the files,
but only the owners of the files can change the files themselves.
- Parallel development is prohibited
Parallel development is prohibited
in shared projects. After an object has been checked out from a shared
project, no one else can check it out.
You must not use a different
version (ccm use command or Use dialog box) and check
out from that version. You might remove the changes of another user.
Instead, check out a working project from the shared project and work
on a parallel version.
- Common work area path required
The work area of a shared project
must be set to a path available to all users. This path must be the
same for all machines. Because all users must access the same work
area from many different machines, the additional network traffic
can slow performance.