UNIX work areas with local files

Consider the following advantages and disadvantages before changing the default.

Advantages

• You can disconnect your local machine and use your work areas.

  This option is most useful to developers.

• Build times might be faster if all files are local rather than accessed through a file server such as NFS.

  For large software teams, the performance associated with building across a file server can make this type of build prohibitive. Use this feature to have your files on the local disk when you build, bypassing the expense of accessing files through a file server.

Disadvantages

• Regular operations are slower.

  You can use local copies to speed local builds, but other daily operations, such as check out, check in, and update, are slower. The daily operations must copy the file back and forth across the network between your database and work area.

• Multiple copies of shared files can present problems if accessed outside of the database.

  With local copies, if a developer has the same working object version in two projects, there are two copies of that file. Each work area has its own copy. The copies of the file have no knowledge of each other.

  During operations, all copies of the file are kept up-to-date in all visible work areas. (A visible work area is one in which the client performing the operation can see the file system location for the work area. If the client sees all of the work areas that a file is in, the client updates each of the work areas during operations.) However, if you work directly in your work area (for example, in FrameMaker), your change is made to the one file in which you are working.

  Note: If you change file copies from multiple work areas without synchronizing or accessing the files through the database between the changes, you create work area conflicts. The conflicts are only resolved with your interaction (that is, by using the Sync option to detect work area conflicts for projects and subprojects).