Sharing between two workspaces issues
Hi,
I am stumped regarding this issue so I will just give as much background as I can. * We have two developers working on different features of a new plug-in to be developed. The idea is that they will finish the functionalities before the plugin is delivered for code review. * Dev A created two plug-in project (main and test) and attached them in separate work items (275 and 276, respectively). He marked the work items completed. * Dev B created a repository workspace to the stream that Dev A is working. He accepted the completed change set in work item 275. The main plug-in project was loaded in his workspace. * Dev B made some changes on the main plug-in and attached it in his work item (286). He completed it and Dev A was able to accept it. They began a few code sharing operations using this method. * Dev B accepted the completed change set in work item 276 to get the test plug-in. * Dev B reconnected to the server and seeing he still doesnt have the test plugin in his workspace, he tried accepting the change set again from 276. An error occured that there is a conflict. * Dev B's pending change view shows that he has unresolved items for the files of the test plug-in project. The files have this marking ".project (Deleted <-> Added)". * We already tried doing a merge using the three available options (proposed, mine, merged) but we cannot resolve the conflict. * I tried accepting the 276 change set on my workspace and got the same problem. * The only option for resolving the files is to either "move" or "rename" them. Move doesn't list the test plug-in project in the options. I already tried creating a dummy project with the same name as the test plug-in but it isn't recognized. Maybe because it is not yet in the repository workspace. * We tried rolling back the 276 change set from Dev A's workspace but I can't see an option for doing it on a completed change set. * From DevA's workspace, we tried delivering the 276 change set to the stream because it only contains the base plug-in project structure. The delivery failed with an error that it conflicts with this error message Cannot deliver changes since they would create conflicts for [UUID_KWsaIVfNEd2vjffO_CQOHA]. Try accepting all incoming changes, resolve conflicts, then deliver again. * Dev A's pending changes view only lists outgoing changes. There are no incoming, suspended, or unresolved change sets. Now here are my questions: * What would be the most prudent action to take here? Sharing-wise, the code development is now in a stand off. * How can we discard changes that are already in the repository workspace? * What would happen to the changes already in the repository workspace but not delivered to the stream if the repository workspace is deleted? What if the change set containing it is already set to completed? * How can we identify the change set that is identified by the UUID in the error message? Thanks. Hopefully somebody would be able to provide guidance before I do something that will aggravate the situation. ciao! |
4 answers
When the connection dropped, it's quite possible that the accept actually completed but the local file area wasn't updated. In those cases, the best action is to refresh the pending changes view and reload the workspace (the reload will be incremental and only bring over the missing files).
Try reloading, then resolve the conflicts. You can also rollback by discarding from your workspace, getting things to work again, then run "replace in <stream>" from the pending changes view to rollback the stream to the same state as your repository workspace. When you delete a workspace, the change sets are still accessible using the change set search feature or by accessing the change sets from their associated work items. The UUID in the error message is a bug. It shouldn't happen unless there is a file which we don't know about (in this case probably the new project). Please open a work item against the Source Control team, so that we can track this problem in general. This could be a bug (we need more information) and is obviously a usability problem. |
|
Hi Jean-Michel,
Thanks for the quick reply. The problem persists and manifests even after doing an unload-load operation on Dev B's workspace. The conflict also arises when I try to create my own workspace and tried to accept the test plug-in changes so this is not restricted to Dev B's workspace. To clarify, when I said discard a change set I meant that the change set and all change information (e.g., the creation of the test plug-in project) will be removed. My intent is to have Dev A discard his 276 work, and then re-do the creation and addition of the test plug-in using another change set. Right now even if we discard the change set from Dev A's pending view, it is still attached to the work item 276. The remove button from the link tab is disabled when I select the change sets. Is there an easy or alternative way to discard the test plug-in folder from Dev A's workspace? I think I will be happy to have it marked as deleted and then delivered to the stream (zero net effect since create+delete operations are on the same delivery) so we can start all over again. Work item 59212 has been logged for the UUID error message. Work item 59213 has been logged for the conflict issue but if it can be resolved here then that would be very much appreciated. ciao! |
Sorry for the delay, did not see your follow up questions.
To roll back your workspace, you can try discarding the change sets from the history view. This will work in some cases, but not always. If this does not work, you can instead replace your component entry with the contents of either a known baseline or stream/workspace, to bring it back to a known point that you can start working with it again. To roll back the stream, what you need to do is to make your workspace look the way you want it to, and then run the Replace In > <flow> action available as a context menu off the component in your workspace. With respect to the association between change sets and work items ... we do not automatically disassociate them when you discard a change, as we do not know if that is really your intention (to truly get rid of them, or just get rid of them for the time being). These links are only removable by the change set author or someone with an administrator role. Hope that helps, JohnC SCM Server |
|
Thanks. I was not monitoring this thread closely since the discussions have transferred to the bug tracker.
Right now I can't provide anything as the stream component just disappeared and we don't know the real cause as the top-level component does not have a history to rule out if somebody deleted the contained files. ciao! |
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.