What do I do when a component "is not shared"?

Andy Jewell (242●3●63●74) | asked Oct 30 '13, 5:52 p.m.
retagged Dec 16 '13, 4:04 p.m. by David Lafreniere (4.8k●7)

On more occasions than I would like, a component in my workspace pops up as "not shared". For example, I am currently getting this:

[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.

On the one hand, it won't let me check changes into the "master" component because it's not shared, but if I try to unload it, it seems to think it's shared.

Am I misunderstanding this output?

- Andy

3 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Simon Eickel (1.1k●7●54●57) | answered Oct 31 '13, 6:16 a.m.

Hi Andy,

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

Andy Jewell commented Oct 31 '13, 11:01 a.m.

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.

Simon Eickel commented Nov 04 '13, 4:22 a.m.

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.

permanent link

Takehiko Amano (1.3k●37●41) | answered Oct 30 '13, 10:15 p.m.
JAZZ DEVELOPER

Have you run "lscm share" command ?

https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/share.html

Comments

Andy Jewell commented Oct 31 '13, 11:00 a.m.

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.

permanent link

John Bayley (1●2●2) | answered Mar 10 '15, 1:08 p.m.

Is there any update regarding this issue? I hit it all the time and it's frustrating to say the least. Add to that errors like the following:

"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

Andy Jewell commented Mar 10 '15, 1:16 p.m.

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.

John Bayley commented Mar 10 '15, 1:24 p.m. | edited Mar 12 '15, 1:08 a.m.

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.

John Bayley commented Mar 10 '15, 1:56 p.m. | edited Mar 12 '15, 1:09 a.m.

Is is possible to list what RTC thinks is shared?

John Bayley commented Mar 10 '15, 3:24 p.m. | edited Mar 12 '15, 1:09 a.m.

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.

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.

It's all about the answers!

Related questions

What do I do when a component "is not shared"?

3 answers

Your answer