Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

CLI - Compare command ordering is wrong / Maximum History limited to 100 entries

 Hi there,

I hope you can help me.
I try to compare a workspace with a baseline and or stream. However the result I get is not correctly ordered.
The changes get ordered by date. This date doesnt match the way they got delivered.
So I end up with conflicts in my workspace, which have actually been solved through future/upcoming changesets.


I use following command to compare my workspace:
lscm --show-alias n --show-uuid y compare ws MYWORKSPACENAME baseline BASELINE -r REPO -I sw -C @@{name}@@{email}@@ --flow-directions i -D "yyyy-MM-dd HH:mm:ss"

Whereas the ordering (they way it has been delivered) is correct when I use:
lscm --show-uuid y --show-alias n show history -m 1000 -r REPO -w STREAM -c COMPONENT

Sadly the show history command is for some unknown reason limited to 100 (latest) entries only.

Is there a way to get all the history or to force that the compare command displays the changesets in the right order (not sorted by date).

We use RTC in version 5.0.1 (For the history problem I found  similar resolved? defect 
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=214396)

0 votes



One answer

Permanent link
Workitem for scm history for a component shows only 100 items: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=272979. Please add your comment in there.

By the way, after the compare operation are you accepting the change sets one by one to the stream? If so, can't you specify all the change sets to the accept command?

0 votes

Comments

Thanks for the reply. It looks like it is exactly that defect. Probably I will reopen the defect (or at least write a comment), since its part of the cli provided by the product, so it needs to be solved in there?

 
To your question: Yes I accept the changesets one by one. If I accept all changeset by once I experience Sockettimeouts and I want to accept not more than one to be honest.

Have you tried changing the value of 'repository.timeout' in ~/.jazz-scm/preferences.properties? That should allow you to choose a long timeout. 


There are some gotchas with ordering change sets, so I suggest avoiding it, if you can. 

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 1,202
× 149
× 113
× 87
× 67
× 35

Question asked: Mar 24 '15, 6:47 p.m.

Question was seen: 5,003 times

Last updated: Mar 25 '15, 10:24 a.m.

Confirmation Cancel Confirm