What do I do when a component "is not shared"?
[tomcat@pzxdcc0131 arfgenpoc]$ lscm checkin master Problem running 'checkin':
"/home/tomcat/.jenkins/workspace/ARFGENPOC/arfgenpoc/master" is not shared.
[tomcat@pzxdcc0131 arfgenpoc]$ lscm workspace unload master
Problem running 'workspace unload':
There are 3 items that are not checked in. Check in the changes or rerun with --overwrite-uncommitted.
3 answers
sometime it can happen that your sandbox does not remember a shared component. This can happen if your sandbox gets corrupt by some things you did faulty.
At this point it helps to "reshare" the component - this means to reconnect the component as it is.
But be aware of loosing non saved changes.
Hope this helps,
Simon
Comments
Should I use the reshare option to share? I haven't got that to work successfully, when I run just the "share" command it seems to re-import everything which - maybe I'm misunderstanding what that does - but I equate that to an svn import which seems like an overkill to correct a workspace hiccup.
it depends which client you are using.
Within the Windows Explorer Client a normal "share" should work.
This works if the structure on your local disc is exactly the same as within the workspace.
A Problem exists, if you have loaded the folder using a load rule the share option will not work as expected. It will create a new folder with the child artifacts you have on your disc.
Otherwise the share should work and should not import everything again. He will check if this exists and skip it.
https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/share.html
Comments
Actually, my question was probably not well worded. This happens after the component has already been created and in use, it spontaneously loses its "sharedness". I do realize I can reshare it which brings every artifact in again. I was thinking there might be a more elegant solution. First preference would be what causes a workspace to forget that a component is shared? Second preference is there something that could reconnect it - I know there is a "reshare" option to the share command but I haven't found that it works.
"Local file system is corrupt. Run repair command to make the workspace consistent.
Unexpected exception
com.ibm.team.rtc.cli.infrastructure.internal.core.CLIClientException: Inverse metadata missing for item [UUID _Dru_MMDgEeS0u4elrr1AGQ]"
and the subsequent inability of the 'repair' command to live up to its name. Then you have errors like:
Problem running 'checkin':
Server error
producing huge core dumps, which suggests that version 5.0.2 is actually version 5.0.2 Alpha.
Comments
I think there were a couple of things I ended up sorting out that really helped with this issue. First, I had two different client versions, depending on which version was being picked up from the path in that particular shell, a different client would be used. This led to problems. Second, I had been routinely co-habitating workspaces with both the Eclipse UI and the CLI. This would put two daemons on the same workspace, it didn't like that very much. Lastly, in general, I try to clean up the daemons more. I don't have any hard proof but it seems to me that when I have fewer detached daemons, I have fewer problems. My first suggestion would be to make sure the client and the server versions match as closely as possible.
Hi Andy,
Thanks for your reply. Currently, my server and client versions match, both being version 5.0.2. My troublesome workspaces were created using the CLI or, in one case, by the Jenkins-RTC integration (which presumably amounts to much the same thing).
I note that I do have a few daemons running so I will try cleaning them up and see if that helps.
Is is possible to list what RTC thinks is shared?
My most recent "is not shared" errors occurred when I attempted to work on more than one component in a sandbox. I was finally able to work around these problems by loading each component in its own sandbox! I hope this saves someone else the four hours it cost me, for what should have been five minutes work.