Delivering to a workspace causes target to go out of sync
Greetings!
I have a chain of two repository workspaces attached to a stream. The first workspace WS1 has the stream as flow target. The second workspace WS2 has WS1 as flow target. I want to use these for testing incoming and outgoing changes in WS1, while actively hacking on WS2. Now, I just developed some change in WS2. I created a changeset and delivered that changeset to WS1. I am now greeted with an unexpected "Some of your projects are out of sync. We recommend you reload these projects. Open Pending Changes view Help to learn more." Firstly, why is the "project" (Note: I'm assuming it is rather the workspace or a component inside the workspace which is out of sync, not the project) out of sync? How am I supposed to propagate changes between the two workspaces without them going out of sync? Do I really have to accept the changes into WS1, which means I first have to fiddle with its flow target, only to revert to the real flow target afterwards? Also, shouldn't RTC at least give me a warning on that? After all, reloading a component can mean data loss if there are changes that should be preserved! Secondly, the error message contains a link to a "Help", which doesn't work for me. When I clicked that link, I first thought RTC had crashed, because it stopped responding. Then, after typing the above three paragraphs, some help view had opened. I clicked on a link there, and again it sat there waiting for ages before I received a 404. That 404 was in a different language than the RTC setup's. I went back (left-pointing arrow button) and selected a different link. I immediately got the 404. However, now I don't have the button to go back in history!? In other words, that help is fubared. Any clue how to fix this? Thank you! Uli |
8 answers
Ralph Schoon (63.4k●3●36●46)
| answered Oct 06 '11, 6:21 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Uli,
I have never used workspaces the way you describe it here. I am also wondering why would you? What is the reason to try to monitor changes that way? You could ignore incoming changes as long as you don't want to deliver and you would see the incoming changes in Eclipse. Have you loaded these workspaces? On the same machine? different or same Eclipse instances? The error messages you are seeing are typically a result of a discrepancy between a file loaded on disk and changes in a workspace. One way to cause it is to change a local file outside of Eclipse without refresh. I am not sure if the other is a change in the repository workspace without accepting the change and altering the file loaded. Can you create a work item for the help topic that did not work? |
I have never used workspaces the way you describe it here. I am also wondering why would you? What is the reason to try to monitor changes that way? You could ignore incoming changes as long as you don't want to deliver and you would see the incoming changes in Eclipse. It's not so much about monitoring. I tend to have a lot of changes locally, some of which might conflict with other changes coming in from my colleagues. Similarly, when finishing a changeset, it is possible that it only works because of the other local modifications. For that reason, I want to have a "clean" workspace, without few modifications at a time where I can test. Have you loaded these workspaces? On the same machine? different or same Eclipse instances? Yes. Yes. Same. Note that I'm only using Eclipse as an RTC client, not as IDE. The error messages you are seeing are typically a result of a discrepancy between a file loaded on disk and changes in a workspace. One way to cause it is to change a local file outside of Eclipse without refresh. I am not sure if the other is a change in the repository workspace without accepting the change and altering the file loaded. I'm sure that no changes to affected files were made in the local sandbox corresponding to WS1. I don't know how I could accept the changes into that sandbox, as soon as I deliver to the repository workspace I get the mentioned error. Can you create a work item for the help topic that did not work? Just wondering, does it work for you? For the record, I'm using RTC 3.0.1 here. Thanks! Uli |
|
Ralph Schoon (63.4k●3●36●46)
| answered Oct 06 '11, 8:00 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Uli,
repository workspaces are meant to isolate changes - being your private stream. There is no automatic accepting of changes so you are in full control of what flows in. You can also run private builds on them. that is the whole idea. If you want to run several repository workspaces with shared code you should use a Stream I think. The clean repo workspace would be used to accept the changes you decide to deliver to your stream. So you are trying to use a repository workspace as a stream. While they are almost identical, I am not sure about how they would react to changes delivered to them. Especially while being loaded. You could try to accept the changes you want to test into the clean workspace (actually flowing the other way around) then the change would be propagated to the loaded source as if working against a stream. You should use two Eclipse instances. I am concerned about having the same eclipse projects loaded multiple times in the same sandbox and the same Eclipse. I am wondering that it lets you because you should have an overlap. Not sure if that is the root cause of your error. |
Firstly, why is the "project" (Note: I'm assuming it is rather the workspace or a component inside the workspace which is out of sync, not the project) out of sync? How am I supposed to propagate changes between the two workspaces without them going out of sync? Do I really have to accept the changes into WS1, which means I first have to fiddle with its flow target, only to revert to the real flow target afterwards? Also, shouldn't RTC at least give me a warning on that? After all, reloading a component can mean data loss if there are changes that should be preserved!This is expected behaviour. When you change WS1 by delivering to it, the content you've loaded to disk for WS1 isn't updated. So you have to reload. For this reason, you are not allowed to deliver to other user's workspaces. You can't alter someone's workspace but you can alter your own because you would know why it went out of sync. https://jazz.net/blog/index.php/2011/09/21/good-practices-and-key-workflows-for-rational-team-concert-source-control-users/ You may want to check out the article on best practices and decide to use suspending and discarding instead of another workspace. I can see the reason for the second workspace but you're eventually going to have to accept the incoming changes. I would just accept and adopt. Might as well do it right away otherwise all the work you're doing doesn't even work with the stream. Or not accept immediately because you didn't intend on adopting the changes right away anyway. If you're really diverging and making big changes, you can create a clone of the main stream. Do all your work there and merge when everything is complete (point #10 in the best practices article). |
This is expected behaviour. When you change WS1 by delivering to it, the content you've loaded to disk for WS1 isn't updated. So you have to reload. For this reason, you are not allowed to deliver to other user's workspaces. You can't alter someone's workspace but you can alter your own because you would know why it went out of sync. What's the use of this other than shooting yourself in the foot, like I did? Anything you could want to achieve with this is still easier by messing with the flow targets of the target workspace, as awkward as that is. Actually, I'm now trying a different workaround for this: I just configured RTC to simultaneously show all flow targets and not just the "current" one. Than way, I can accept from multiple targets without having to fiddle with the workspace there. Pushing the CS to the target workspace is then replaced with pulling it from the source workspace, which is acceptable. Uli |
|
Delivering to a tracked workspace won't cause this out of sync behaviour because it isn't loaded to disk. It's for users that want to deliver between workspaces and streams because they're handling the movement of changes and don't require loading content.
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 06 '11, 6:07 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, accepting into the target workspace, rather than delivering to the
target workspace, will avoid the out-of-sync problem. I've submitted work item 179832, requesting that only accepting into a workspace be allowed, and not delivering into a workspace (for this and other reasons, mentioned in the work item). Please feel free to add a comment indicating your interest/support for this usability enhancement. Cheers, Geoff On 10/6/2011 12:08 PM, ulricheckhardt wrote: This is expected behaviour. When you change WS1 by delivering to it, |
|
|
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.