Work with projects and streams in Eclipse
Dimensions CM for Eclipse provides access to Dimensions CM source control functionality using projects and streams.
Dimensions CM source control
You can perform Dimensions CM source control actions, such as check in and check out, directly from the Eclipse environment.
You can map Eclipse projects either to Dimensions CM projects or Dimensions CM streams. For details, see Use projects or streams.
You can also group multiple projects into a project group, or organize Eclipse projects into project containers. Project containers are a special type of Dimensions CM project that may contain more than one IDE project. For details, see Use Eclipse project containers.
The Eclipse project files are placed into the Dimensions CM repository based on the mapping.
When you add your Eclipse projects to the Dimensions CM repository, Dimensions CM stores information about the Eclipse project, such as integration type and project name, in the Dimensions CM repository.
Eclipse project data
When you add an Eclipse project to Dimensions CM control, Dimensions CM stores additional data about the project, such as the IDE type (Eclipse), the actual project name in Eclipse, and other project specific information.
The information is stored as attributes for the Dimensions CM project that is associated with the Eclipse project.
This information is stored either as a project marker file with the extension .ecl (when working with Eclipse containers), or as attributes for the Dimensions CM project or stream. Additional information is associated with Eclipse Project Containers that allows them to be explicitly identified in the Dimensions CM Explorer.
Use projects or streams
To work with your Eclipse projects, you can use Dimensions CM projects or streams:
Dimensions CM projects | Use Dimensions CM projects to explicitly check files out and in when working on them. Projects may be most useful for teams for whom more cautious day to day version management is critical. For example, this may include large teams whose members work concurrently on the same files, or teams working on the main line of development for a product. For details, see About projects. |
Dimensions CM streams |
Use Dimensions CM streams to manage parallel development efforts that do not require explicit file checkout. Streams enable teams working on parallel lines of code to work in a more agile fashion to build and deliver patches and maintenance releases without having to continuously reconcile against the main lines of development. For details, see About streams. For details about topic streams and pull requests, including examples and scenarios, see Topic streams and pull requests. To work with streams:
|
Dimensions CM project containers | Use Eclipse project containers to group multiple Eclipse projects under a common Dimensions CM project. For details, see Use Eclipse project containers. |
Optimistic locking
Optimistic locking enables you to check in files that were not checked out.
You check in the updated workfile to the repository directly, or if the repository revision has changed, you merge the local file and the repository revision and then check in the changed file into source control.
Optimistic locking differs from the classic pessimistic approach, where you have to explicitly check out the file before being able to place the updates into the repository.
Optimistic locking works well in an Eclipse development environment where developers are working concurrently on projects. A developer may have the entire project locally and need to make changes, but he may not know which files are affected until beginning work on the code. Optimistic locking allows the developer to alter the code, and then only check in the files that have been changed.
Dimensions CM provides both optimistic and pessimistic options. In Dimensions CM streams, files are writable by default.
Note: You cannot enforce either optimistic or pessimistic mode in Dimensions CM from the server level. As an Eclipse user, you may set preferences within Eclipse to facilitate one approach or the other. For example, you can require a checkout before editing files (Pessimistic locking approach).
See also: