Reasons for sharing files
Return to Introduction  Previous page  Next page
There are many situations where you may have some shared code that is used by several projects. The code may be utility routines or components, but exactly the same code is used in each project.

One way of handling this is to have a copy of the shared files in each project, but changes made to one copy of the file will not be reflected in the other copies. A far better method of sharing components is to have all projects share the same copy of the component archives. Thus, any changes will be reflected in all projects.

When defining your project structure in Team Coherence, it is good practice to create a single project that can be used to hold all shared files. When files or components that are likely to be shared by other projects are added to the repository, they should be added to this project (this can also be done retrospectively using drag-drop).

This is all very well, but what do you do when assigning Version Labels and carrying out other actions (for example getting the latest copy of the shared components). In this case, you would have to remember to assign the Version Labels being assigned to a project to the individual shared components it uses (that are contained in another project or folder). This is tedious and prone to errors.

To simplify this process and to associate the shared objects with any project or folder, Team Coherence supports the concept of Virtual Archives.

 


© 1995-2018 MCN Software