Changeset alias id no longer existing within the same login session
RTC 3.0.1 used
We use scm command to compare two streams and then find out the changesets. We then filter the changesets and only deliver specific changeset by specifying changeset alias id scm login -r https://xxx:xxx/ccm -u user1 -P userpwd -n test scm compare -r test stream DEVStream stream STSteam scm deliver -r test -s DEVTest -t STTest -c 1234 The deliver complains that changeset id not existing. This takes place recently only when there are a lot of difference during compare and the filter process may take more time than usual. According to the discussion in: https://jazz.net/forum/questions/76093/changeset-alias-numbers It says: Don't rely on the alias. This can change from session to session. It is a temporary id that helps you during your session but isn't guaranteed to always be the same. My understanding is that the above session means the user is in same login session, which in this case, it is the same login session. However, the alias id shows in the compare is no longer existing in the later deliver stage which does not make sense. My question is: 1) is the above session means login session? 2) In this case, will the same login session have timeout concept? When delivering the specific changeset with scm deliver -r test -s DEVTest -t STTest -c 1234, does alias no longer existing mean the previous login session is timeout or whenever -r test used, it is another login session and alias id is not guaranteed to be the same as before? or we can make timeout longer(if timeout does exist) and use scm deliver -s DEVTest -t STTest -c 1234 (withou another login ) to deliver the same changeset by alias id? 3) If there is no guarantee in any session regardless session timeout or not for alias id delivery in scm command, will scm deliver -r test -s DEVTest -t STTest -c UUID work or only -c alias is supported? Thanks in advance. |
One answer
Aliases should last at least until the next CLI command is run. ie, if you run 'scm status' and see an alias, you can use it in the next invocation of the command line.
To answer your numbered questions:
1) Session isn't meaningful in this context. It definitely doesn't mean between an 'scm login' and 'scm logout' since we make no guarantee that aliases last anywhere near that long.
2) There is no timeout. There is an internal hardcoded limit of 1000 aliases stored in a least-recently-used queue. If a new item is shown on the output, an alias is removed from the end of the queue and a new alias is assigned.
3) UUIDs can always be used in place of aliases. I believe that most (all?) of the places where they are used is documented in 'scm help' output. In the example of 'scm deliver':
-c [--changes] - Indicates that the selectors refer to change sets and only the specified change sets must be delivered. To specify a change set, use its alias or UUID[@repo] in the list of selectors. Comments 
Dejan Custic
commented Nov 15 '12, 5:24 p.m.
| edited Nov 16 '12, 10:29 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
FYI, the Help SCM deliver example is here http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/topic/com.ibm.team.scm.doc/topics/deliver_ex.html
Thanks for Evan's answers and Dejan's info.
We don't expect users to use UUIDs unless they absolutely have to. For day to day stuff, aliases should be sufficient.
(A corrollary to this is that we don't expect users to show 1000+ items in the output of the CLI - I expect that only occurs when there are a couple of workspaces/streams that are far out of date)
|
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.