Product HCL Launch. Type plugin. Compatibility HCL Launch version 7. Created by HCL Software. Website Rational Team Concert. Updated Date June 25, Ask a Question. Version Name Modified date Action 7. This plugin runs with Rational Team Concert version 4.
This plugin supports all operating systems that are supported by the HCL Launch agent. History The following table describes the changes made in each plugin version. Added tracking of user who requested a manual version import. Create a component To create a component, complete the following steps. In the Create Component window, specify a name and description for the component.
In the Teams fields, specify the access information for the new component. The final step is to deliver the change from our workspace to the stream so that the changes are available to all the team members of the project. If no options have been specified to the deliver subcommand, it will deliver all the changes from all the components to the stream.
In a project, team members will be working on changesets and delivering these items to the stream. We need to be always in sync with the stream so as to ensure that we are working with the latest copy of the code.
Let us suppose that there were some changes made by another developer say userB in the src folder. To check whether our copy is up to date with that of the repository, we need to run the show status subcommand. As we see, there is one incoming change set alias with 2 changes in it. To get the latest from the repository, we use the accept subcommand.
Similar to the deliver subcommand, the accept subcommand can accept changes from specific components or baselines or change sets or work items into the workspace. Suppose we want to update our workspace from another stream, we do this by changing our workspace target flow to the new stream. After we change the target flow, we may see incoming and outgoing changes between our workspace and the target stream if there are any.
Notice that Workspace1 now flows to Workspace2 and we see an incoming change that developer B had created in Workspace2. We can now accept this change and test that functionality. Once we are done with our testing we can change our target flow back to Stream1. Let us consider a scenario where there is a new incoming change by userB from the stream and there is also an outgoing change from our local workspace both modifying the same file.
In this case, there is a conflict between the incoming change and the outgoing change that has to be resolved. The show status subcommand below shows that there is a potential conflict. To get more details on the conflicts, we can use the show conflicts subcommand. We can have user properties for files and folders. The resolve conflict subcommand behaves the same way whether it is for content conflicts or property conflicts.
It is important to note that accepting the changes will merge all non-conflicting regions automatically. To disable auto-merge, use the --no-merge option in the accept subcommand. In our above example, if we had used the -i option, the merged file will have the following content:. Could not load branches. Could not load tags.
Latest commit. Git stats commits. Failed to load latest commit information. View code. Contribute Pull-Requests Wiki.
To avoid an account creation on the jazz. Usage Create a config file called config.
0コメント