It's all about the answers!

Ask a question

Not able to view multi stream history using "Show all in repository" though used common component for all streams


Ashok Sharma (3211118) | asked Aug 28 '14, 5:13 a.m.
Hi All,
I have a problem, what i have done is, i have migrated three streams (say Stream1, Stream2 and Stream3) using command line approach. Now when is select "Show all in repository" option in History view for a file in Stream1, i cant see change set which was delivered for same file in Stream2 and Stream3. Though i had used same component name for all three streams so RTC should maintain multi stream history.

I have used command line approach for migration. Below are the steps i had used
1. Created stream using lscm create stream command.
2. Created workspace using lscm create ws command.
3. Popup from accurev into some location.
4. Making above location as sendbox using lscm load command.
5. Created/associated component using lscm create component (in first run) and lscm workspace add-component (for subsequent runs).
6. Then sharing sendbox with RTC component.
7. Then lscm status and lscm checkin and finally lscm deliver.

This approach creates only one component say MyComponent and created three streams Stream1, Stream2 and Stream3 with component MyComponent.

But since i am not able to see multi stream history i doubt if instead of same component name RTC considering File1 as independent file in all streams?

Thanks in advance. 

3 answers



permanent link
Tim Mok (6.6k38) | answered Aug 28 '14, 11:39 a.m.
JAZZ DEVELOPER
Change sets don't have delivery information recorded anywhere. If you want to see the differences between two streams, you can compare them. If you want to see if a change set was delivered to a stream, use the locate change sets feature.

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 28 '14, 12:13 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Aug 28 '14, 12:19 p.m.
I'm guessing that what is happening is that you each time you do a "share", you are doing it on an empty workspace, which means each share is creating what ClearCase would call an "evil twin" of each of the files in the sandbox.   What you need to do to avoid this is to re-use the workspace that you used to import the previous stream ... then delete all the files in the sandbox (except for the .jazz5 directory), and then copy the files from the new stream you want to share into the sandbox, refresh the pending changes view of the sandbox, and then check in the Unresolved changes.  This way, RTC will detect that files with the same name should go into the same history.   (This is described from a GUI perspective ... you can also do this via scripting and the command line).

Comments
Ashok Sharma commented Sep 04 '14, 10:48 a.m. | edited Sep 05 '14, 6:39 p.m.

 Thanks Geoffrey for you response. I tried what you have suggested.


Used same component, sendbox () and workspace for migration. For every next stream first deleted all the files in the sandbox (except for the .jazz5 directory), and then copied the files from the new stream.

In my case first stream (Stream1) has say three folders at root level say srctest and and xsd and second stream (Stream2) has only one folder src. When my script migrates Stream2 i get below error 

      -c- /src/uiResource_z1.properties.utf8
      -c- /src/uiResource_zh.properties.utf8
      d-- /test
      d-- /xsd


>>>> Checking in to RTC...


>>>> Start of check-in log:

com.ibm.team.repository.common.TeamRepositoryException: /test does not exist and cannot be checked in.
        at com.ibm.team.filesystem.client.internal.rest.util.CommitUtil.addRequest(CommitUtil.java:165)
at com.ibm.team.filesystem.client.internal.rest.util.CommitUtil.getCommitOp(CommitUtil.java:127)
        at com.ibm.team.filesystem.client.internal.rest.util.CommitUtil.checkInChanges(CommitUtil.java:94)
        at com.ibm.team.filesystem.rcp.core.internal.rest.FilesystemRestClient.postCheckInChanges(FilesystemRestClient.java:859)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at com.ibm.team.filesystem.client.daemon.JSONHandler.handle(JSONHandler.java:322)
        at com.ibm.team.filesystem.client.internal.http.HttpConnection.readNextRequest(HttpConnection.java:628)
        at com.ibm.team.filesystem.client.internal.http.HttpConnection$1.run(HttpConnection.java:470)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
        at com.ibm.team.repository.common.internal.marshal.util.MarshallerUtil.decodeExceptions(MarshallerUtil.java:328)
        at com.ibm.team.repository.common.serialize.internal.JSONDeserializer.deserializeErrorObj(JSONDeserializer.java:955)
        at com.ibm.team.filesystem.client.internal.marshalling.ExceptionHandlingJSONDeserializer.deserializeErrorObj(ExceptionHandlingJSONDeserializer.java:128)
        at com.ibm.team.repository.common.serialize.internal.JSONDeserializer.deserializeException(JSONDeserializer.java:933)
        at com.ibm.team.filesystem.client.internal.marshalling.EObjectJSONDeserializer.deserializeError(EObjectJSONDeserializer.java:71)
        at com.ibm.team.filesystem.client.restproxy.RestInvocationHandler.executeRequest(RestInvocationHandler.java:267)
        at com.ibm.team.filesystem.client.restproxy.RestInvocationHandler.executeAndReturnResult(RestInvocationHandler.java:221)
        at com.ibm.team.filesystem.client.restproxy.RestInvocationHandler.invokeInternal(RestInvocationHandler.java:368)
        at com.ibm.team.filesystem.client.restproxy.RestInvocationHandler.invoke(RestInvocationHandler.java:311)
        at com.sun.proxy.$Proxy1.postCheckInChanges(Unknown Source)
        at com.ibm.team.filesystem.cli.client.internal.subcommands.CheckInCmd.run(CheckInCmd.java:166)
        at com.ibm.team.filesystem.cli.core.AbstractSubcommand.run(AbstractSubcommand.java:51)
        at com.ibm.team.rtc.cli.infrastructure.internal.core.SubcommandLauncher.run(SubcommandLauncher.java:534)
        at com.ibm.team.rtc.cli.infrastructure.internal.core.SubcommandLauncher.doStart(SubcommandLauncher.java:356)
        at com.ibm.team.rtc.cli.infrastructure.internal.core.SubcommandLauncher.run(SubcommandLauncher.java:125)
        at com.ibm.team.filesystem.cli.client.internal.daemon.CommandLineClient.handleRequest(CommandLineClient.java:154)
        at com.ibm.team.filesystem.client.internal.http.ProtocolSwitchingHttpHandler.handle(ProtocolSwitchingHttpHandler.java:46)
        at com.ibm.team.filesystem.client.internal.http.HttpConnection.readNextRequest(HttpConnection.java:628)
        at com.ibm.team.filesystem.client.internal.http.HttpConnection$1.run(HttpConnection.java:470)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Problem running 'checkin':
Exception running commit operation

>>>> End of Check-in log:

Changeset =

>>>> Delivering to RTC...

Delivering changes:
  Repository: ########
  Workspace: (1454) "ESP_Src_SSO_JDK1.1"
    Component: (1450) "SSO_Component_New1"
Deliver command successfully completed.
~/RTC-Migration/New-Script/FinalSSO

And when i check Stream2 it has test and xsd folders as well but those should have been deleted. 

Please help me to solve this problem. Thanks in advance.


Geoffrey Clemm commented Sep 05 '14, 6:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Unfortunately, I have only limited command line expertise ... so we'll need a command line expert to comment on the above problem.   You probably would need to include your script, and you probably should instrument your script with print statements saying where it is in the script (so that it is clear what command is having trouble).


Lily Wang commented Sep 07 '14, 10:48 p.m.

Hi Ashok,

For the "scm checkin" error "com.ibm.team.repository.common.TeamRepositoryException: /test does not exist and cannot be checked in."
 You can use "scm checkin -D". If it still doesn't work, you may hit the defect https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=255197


permanent link
Winston Enos (33116) | answered Aug 28 '14, 12:27 p.m.
edited Aug 28 '14, 12:28 p.m.
Ashok Sharma,

Explain to us what you are actually trying to see here, because that is the confusing part. Because this is working exactly as I expected it to on my end.

As I understand you have 3 streams (Stream1, Stream2, and Stream3) each flowing the same component, MyComponent.

First off, are you 100% sure this is the case? Out-of-the-box RTC allows people to create components with redundant names, it could be possible you accidentally created duplicate components with the same name but they are actually different components. If you go under the project to Source Control and select 2 of the streams, you can 'Compare With' -> 'Each Other', make sure you don't see incoming or outgoing components. Do the same with the other streams against each other as a sanity check.

As I understand it, you now have a file inside the component that you have made a modification to and delivered to a specific stream, correct? At this point, what exactly are you expecting to see?

In my environment I have a file 'foo.java' in a component that is shared across 4 different streams. The users made changes to the file in stream 1 that aren't in any of the other streams. In stream 2 they merged stream 1's changes into a new changeset that is only in stream 2 and none of the other streams. Streams 3 and 4 don't have any additional changes.

When I right-click this file and do a Show History from the perspective of Stream 1 I see all the changesets leading up to the change in this stream. When I select 'Show All In Repository' I see the latest changeset from stream 2 display at the top. Streams 3 and 4 had no additional work on this file so obviously they have nothing to contribute.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.