Potentially serious issue with SCM
Hi again
I am hoping we have just missed something or don't fully understand how the SCM works , but using 2.0.0.2 ( I thin this is the same on earlier versions too ) we have seen some worry behaviour. You create a file and when placing it into SCM you associate it to a work item. Checking it in and I can see it in my repository workspace. I then deliver it to the main team stream and all looks well. Checking the work item I can see an associated change set but when I click on it, the file it shows is in My Repository's stream and not the main team stream. Deleting My Repository ( which we do to clear our workspaces up ) and then following the change set though the work item shows the item linked to an 'unknown workspace'...... Why did it not associate it the team stream or what is the work around? cheers David |
4 answers
Ralph Schoon (63.3k●3●36●46)
| answered Jan 07 '10, 8:55 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
David,
if you delivered the change set to a stream it will be in the stream. If you click on the change set in the work item it says it can not "resolve" the workspace it is in. It tries to locate the file on your disk in your repository workspace. If none is loaded it can't find it, hence the message. But in the last line is a link that allows you to fix that e.g. by selecting a Stream. If I click on a file in the changeset it also shows the particular change in the repository. To find the change in a stream, you can also right click the change set and select "locate change set". then select the candidate stream etc. At least that is what I am seeing, Ralph Hi again |
Change sets can be interpretted in different workspaces, they have a
completely different lifecycle. We do not associate a change set with a particular stream as that stream could as well be deleted. Hope this helps, JohnC SCM Server daviesd wrote: Hi again |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jan 07 '10, 2:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To expose some gory details, what is done under the covers is that when
you create a link between a work item and a change set, if it has a workspace context for that change set, it annotates that link with the ID of that workspace. It can then use this link when displaying the files in that change set, to have a reasonable workspace within which to resolve the pathname. But if you delete that workspace, it can no longer use that hint. Not sure when exactly this feature got added, and not sure in exactly which contexts this link is annotated as described above, or for that matter, whether the description is exactly right (:-). But it gives you an idea about what is probably causing the behavior you are seeing. Cheers, Geoff rschoon wrote: David, |
A change set is selfcontained, it's got the before and after states for the files that are being changed. From this we know the file names and most everything else. However, since a file can appear in different file trees, we can't compute the entire path without having a stream or repo workspace as a context to resolve the full paths.
When you associate the work item, we store a hint, so that we don't have to prompt you all the time to pick a stream/repo workspace. Cheers, Jean-Michel |
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.