Error sharing (adding) a component
John Bayley (1●2●2)
| asked Aug 06 '13, 4:30 p.m.
retagged Aug 13 '13, 7:31 p.m. by Te-Hsin Shih (285●4)
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 exceptionCould 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
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? |
|
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 |
|
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 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:
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?
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 Regarding the use of 'load' and 'checkin,' thank you for the confirmation about their use.
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.
|
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.