lscm accept command is not detecting changes
I'm using the following command in order to accept changes that had been checked-in and delivered already into RTC workspace.
lscm login -r <url-to-my-rtc> -u <username> -n rtc -P <password>
lscm accept -r rtc -d /Codes/rtc -t <workspace name> -C <component name>
lscm logout -r rtc
The change sets have been delivered, but the accept command simply tells me "Workspace unchanged". There's no other error messages.
Do i have a typo anywhere in the command or is there something I need to check in the workspace?
2 answers
Are you sure the change has been delivered to the same stream that this workspace has set as it's flow target?
Is the change in the component you are listing?
Have you tried running "scm status" before accepting?
Comments
Hi Melissa,
Thanks for your reply. As far as I can see, the changes have been delivered to same stream. In my RTC client, I can see the changes on that particular component as "Incoming"
I resolved the "Workspace Unchanged" error but still can't get the changes accepted. I had 2 different processes/daemons running with slightly different name for the local directory where the workspace was loaded. I removed both of those and re-loaded the workspace.
After that I re-ran the lscm accept command to accept the changes and download those into that same local directory. This time instead of getting "Workspace Unchanged", I'm getting "There are 1 items that are not checked in. Check in the changes or rerun with --overwrite-uncommitted"
What does that mean? I just loaded the workspace locally from RTC. Didn't make changes to any files locally. Why is it saying I have items that haven't been checked in?
This is saying that RTC has detected changes to the sandbox (what RTC calls an "unresolved change", which means "a change that has not been checked in", or what other systems also call a "checkout"). It doesn't want to overwrite those unresolved changes with the incoming new versions, so it is suggesting you checkin those changes (which capture them in a change set). You can then decide to suspend/discard that new change set before doing the accept, or keep those changes and merge them with the new changes being accepted. I personally would never use the --overwrite-uncommitted flag ... and in fact, if I had my way, I wouldn't even provide that option (:-).
Thanks Geoffrey for your reply. I'm fairly new to RTC, but if I understand it correctly, the sandbox is basically a local directory where a copy of all the files in the workspace has been downloaded (which I did by using lscm load command).
So, I don't understand why the system is saying I have an item to be checked in. As I mentioned, I didn't modify anything on the local copy. In fact, I ran the "lscm accept" command right after the "lscm load" was completed successfully. So, the local copy should be same as what's in the workspace (minus the incoming changes).
How can I find out which file on the local copy/sandbox hasn't been checked-in? It still doesn't make sense to me.
It is a bit strange. You can try running a checkin to see what it considered changed (and as Geoffey mentioned, you can choose to discard or suspend after). Perhaps it is a permission change....
The unresolved items had "p" flag beside them, which according to the following resource indicates the properties of the file has changed.
http://www.ibm.com/developerworks/rational/library/rational-team-concert-command-line-reference/
This is what I find confusing. I performed the same operation multiple times, with same result.
1. Run "lscm load" command for loading the workspace into a local directory (previously created local directory was removed)
2. Run "lscm status" from the local directory, where the workspace has been loaded.
--> The status shows all files in every single component as unresolved
With the help of my colleague when we checked-in one of the files being reported as "Unresolved", we compared the difference from RTC GUI. The difference it showed was that the new file's executable property was changed to "true", even though the file's property wasn't showing it as executable on that same local directory.
Not sure if this is a bug or not. I'm using RTC 4 and ran into this issue on AIX 6 machine where I was loading the workspace and was trying to accept the changes.