suspected bug in lscm changeset associate command - looking for workaround
I have a couple of lscm commands I use in my migration tools, I operate by firing an scm daemon for the sandbox then firing lscm commands and processing the error codes. For some odd reason the associate command now try's to use a different server to the one I log on to, looks like a bug, or perhaps I am doing something wrong I have a fairly complicated migration script that is now being used quite extensively. Note that this problem has only just started happening, have used exactly the same command for a number of previous migrations with no issue
C:\PROGRA~2\IBM\TEAMCO~1\scmtools\eclipse\lscm login -r https://prodServerName/ccm -n ThisConnection -u myUser -P myPass
Note my original second line was: - C:\PROGRA~2\IBM\TEAMCO~1\scmtools\eclipse\lscm -u yes changeset associate -r ThisConnection _gQEN4JTwEeWE7K32ubefvA 1257 but I thought I'd try giving the associate all the connection details directly. Note sandbox has been successfully checked into the repository workspace. I am using RTC 5.0.2, no prospect of updating any time soon. Stuck - please help ;-)
Sorry - I need to be more explicit. Why is the changeset associate command trying to use a server I have not referenced in my login command or the changeset associate command, I should not be being asked to provide a password to an RTC instance I have no interest in! - seems very odd - note the server that it is trying to connect to is the last one that was installed if that makes any difference, suspect it might be something to do with using the internal changeset GUID.
|
One answer
Shashikant Padur (4.3k●2●7)
| answered Nov 29 '15, 10:24 p.m.
JAZZ DEVELOPER edited Nov 29 '15, 10:25 p.m.
You have hit the following defect: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=309555
The issue is that the tool is considering 1257 as an alias rather than a workitem. I believe the alias 1257 is pointing to some item in the https://DevServerName:9443/ccm/ repository.
To workaround this issue, delete the existing aliases.txt file that could be found in your <user_home_dir>/jazz-scm directory. Note: Aliases are used as a convenient way to refer to an item. When using in scripts run all the commands with '-a n' option to the scm/lscm commands. For example: 'scm -a n changeset associate ....'
Comments That does sound more than plausible - thanks! Not sure I would have got there without you. You imply that the -a n command line will solve my problem. I do not want to delete this alias file every time I run the script, are you saying I have to or is the -a n tweak sufficient? I will add the -a n to all my lscm commands and report back when I'm called upon to do some more migrations. Having the option '-a n' indicates do not show the alias or write to the alias file. So you do not need to delete the alias file every time you run your script.
But I believe it may validate the alias if it is found in the alias file (not sure though). I would suggest deleting the alias file at least once so that you start with a clean slate.
|
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.
Comments
Note I'm well aware this sounds like finger trouble, but it isn't ;-)