I am trying to use the RTC lscm
CLI tool to promote change sets from my dev stream (i.e. from a dev stream workspace) to my test stream.
When I try promoting the change set, 90% of the time I get something like this:
[me@buildvm02 logs]$ lscm deliver -c 1802 -v -r https://mycompany.com:9443/jazz/ -u build@mycompany.com -P passw0rd -t "Dev Stream Workspace" -s "Test Stream"
Unresolved change sets:
1802
Problem running 'deliver':
Unable to resolve change sets.
(for the record, I tried both with aliases like 1802 above and with the change sets' UUIDs starting with underscores)
With very few exceptions, the command always fails.
I tried running lscm
in verbose mode and looking at the documentation but nothing really helped. To be fair, I don't even know what an "Unresolved change set" means. It doesn't mean that the change set can't be found, since I simulated the command with bogus change set ids and I get a proper error message saying the change set doesn't exist.
Any ideas?
That looks like the change set 1802 is the result of applying a patch from the Pending Changes view.
You can see an example in this thread "Reversing a work item with two change sets"
Right-click on
CS2
in the History view and select "Reverse
". This will add a pending patch to the Pending Changes view. Now you can either try to 'auto-resolve' the changes if nothing conflicts, otherwise you will have to manually merge the changes.
Whether it auto-resolves or if you manually merged the changes, it will appear as an unresolved pending change in the "Unresolved" folder. You can now check-in the file changes into a new change set. To help you can also name this new change set "reversal of CS2". You can then deliver it to the stream.
So check if you can do the same and first check-in 1802 as a new change set, then deliver it.