It's all about the answers!

Ask a question

Error sharing (adding) a component


John Bayley (122) | asked Aug 06 '13, 4:30 p.m.
retagged Aug 13 '13, 7:31 p.m. by Te-Hsin Shih (2854)
I have created a compoent in a workspace. Next, while running a command of the following form, from that sandbox:

$ lscm share -r repo <workspace> <component> *

I get the following error:

Unexpected exception
java.lang.IllegalStateException: The rule MultiLock(ComponentLock(/path/workspaces/DataSync_1.1_ws, _nXUFQP4QEeKkSNfLOuIhKA, _9kEQsf7TEeKHwfepocDmaA), ComponentLock(/path/workspaces/DataSync_1.1_ws, _VsE1kPt-EeKkSNfLOuIhKA, _WljbQft-EeKkSNfLOuIhKA)) is not promotable from the base rule ComponentLock(/path/workspaces/DataSync_1.1_ws, _nXUFQP4QEeKkSNfLOuIhKA, _9kEQsf7TEeKHwfepocDmaA)
Could someone translate that to English (Queen's English preferred, but other dialects are fine too)? That may in itself be enough, but suggestions of common causes and workarounds are welcome too.

Thanks,
John

3 answers



permanent link
John Bayley (122) | answered Aug 07 '13, 6:12 p.m.
Background: I am trying to upload source code from another source control system to RTC.

Thus, to answer your first question, I (believe I) need to specify "*" to the share command in order to share all sources in the workspace, all of which are new to RTC.

The steps I followed are:

(1) Create an RTC stream.
(2) Create an RTC workspace based on the stream created in step (1).
(3) "Load" the RTC workspace created in step (2), to create a sandbox on my local machine.
(4) Create an RTC component, associating it with the workspace created in step (2).
(5) Make the component created in step (4) visible at the project level.
(6) Download the source code from the other source control, into the RTC sandbox created in step (3).
(7) "Share" the source code downloaded in step (6), using 'lscm share -r repo <workspace> <component> *'
(8) Check-in the "shared" files.    // Question: What is this doing that 'share' hasn't already done?
(9) "Deliver" the checked-in files.

The problem mentioned in my original question occurs if I need to re-run the above sequence of operations for some reason. In that case, I have carried out the following steps:

(a) It appears impossible to delete a component. // Question: Is it possible to delete a component?
      My workaround, for now, is to rename the component created in step (4).
(b) Remove the (renamed) component from the stream created in step (1). Delete the stream.
(c) Remove the (renamed) component from the workspace created in step (2). Delete the workspace.
(d) Delete the sandbox created in step (3), including the parent of the .jazz5 directory (and, thus, the .jazz5 directory itself, which is no longer relevant).

That done, repeating steps (1) to (7) will result in the "MultiLock"/"ComponentLock" error that I originally quoted.

As I mentioned, this can be worked around by choosing a different physical location (i.e. sandbox location) for the "load" command.

Again, I can only believe this is a bug. There appears to be some stale metadata in RTC itself (i.e. nothing to do with the metadata in the .jazz5 directory) linking the physical location to a (renamed) component.








Comments
Shashikant Padur commented Aug 08 '13, 6:14 a.m.
JAZZ DEVELOPER

You use share command to share the code the first time into your repository workspace. After that for any modifications to the code you can run the checkin command. By the way, you can achieve what you are doing with the following steps:

(1) Create an RTC stream.
(2) Create an RTC workspace based on the stream created in step (1).
(3) Create an RTC component, associating it with the workspace created in step (2).
(4) Make the component created in step (4) visible at the project level.
(5) Download the source code from the other source control, into to a directory.
(6) "Share" the source code downloaded in step (6), using 'lscm share -r repo <workspace> <component> *'.
(7) "Deliver" the change set (checked-in files).

There is no component delete support available yet.


John Bayley commented Aug 08 '13, 9:20 a.m. | edited Aug 08 '13, 9:21 a.m.

Thank you for the work-flow feedback. To summarise, you are saying that it is unnecessary to both "load" the workspace and to run the "checkin" command?

Will component delete be supported in the future?

Do you have any comments regarding my original problem/question? That is, regarding what appears to be a bug when you try to re-use a physical sandbox location?


Shashikant Padur commented Aug 12 '13, 12:50 a.m.
JAZZ DEVELOPER
Yes, for the above scenario load and checkin is not necessary. The share command will upload the files to the repository workspace and the directory will be tracked by RTC.

With respect to the re-use of the sandbox location... lscm runs a daemon process in the background and that is still tracking the sandbox location. Run 'scm ls daemon' it should list all the tracked sandbox locations. To terminate the daemon, run 'scm daemon stop <sandbox loc>' or 'scm daemon stop -p <port>'

You can track the status of delete component work here... https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=163568




John Bayley commented Aug 13 '13, 6:34 p.m.

Regarding the use of 'load' and 'checkin,' thank you for the confirmation about their use.

With respect to re-using a sandbox location, would it not make sense for the removal of a repository workspace to also run 'scm daemon stop <sandbox loc.>'? The fact that it doesn't really seems like a bug to me.

Thank you also for the work item about the status of deleting components.


Shashikant Padur commented Aug 14 '13, 7:46 a.m.
JAZZ DEVELOPER

Probably you are talking about unloading a workspace. Yes, if only one workspace was loaded in the sandbox, the unload workspace probably could de-register the sandbox from the daemon.
By the way, you could also run 'scm daemon deregister' instead of stopping the daemon. If the daemon does not have any sandbox registered it will be reused with a new sandbox. The daemon usually has a lifetime and would terminate if it is inactive for a certain duration.


permanent link
John Bayley (122) | answered Aug 06 '13, 6:15 p.m.
Some further background:

I had previously used the same location on my local machine to 'load' a repository workspace (i.e. to create  a sandbox). I had also successfully executed the 'share' command shown above. My test failed later in the process, but I wished to start again from scratch.

It appears that components cannot be deleted (why?!?), so I renamed my existing component. I removed that renamed component from my repository workspace before deleting that repository workspace. I also deleted the local sandbox from my machine (including, it should be noted, the CVS-esque .jazz5 directory).

However, it appears that RTC keeps some metadata tying that sandbox _location_ to the (now renamed and unwanted) component that prevents you from sharing files to a component using the same sandbox location ever again!

That seems like a bug to me.

Workaround:
- You can create a new component with the same name as the original component.
- You can create a new repository workspace with the same name as the original repository workspace.
>>>> You have to 'load' a repository workspace into a new sandbox location, however. <<<<


However

permanent link
Shashikant Padur (4.2k27) | answered Aug 07 '13, 1:58 a.m.
JAZZ DEVELOPER
Since you specified '*' to the share command, it might have tried to share the existing path (which was already shared to some component) to the component. This might have resulted in an exception although it should have spit out a better error message.
Can you just specify the path you want to share and see if it works? Also, can you specify the exact steps?

By the way, if you have deleted the .jazz5 directory (that has the metadata) then that directory will no longer be tracked by RTC. What is the error you encountered when you tried to re-use that directory or what is the operation that you ran with respect to that directory?

Your answer


Register or 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.