Why are paths displayed as unresolved in the Change set summary?
Hello together,
I have one question without a loaded repository workspace I get following message if I open a Change Set in the Change Summary or Change Explorer.
My question is now why can't RTC resolve the path without selecting a stream or a repository workspace?
And how is the path location saved that with a stream or repository workspace it is possible?
Thanks for your answers.
Regards
Tobias
Accepted answer
Tobias Burkhardt ,
This was answered by a Jazz developer in another question:
https://jazz.net/forum/questions/103431/urgentfetch-the-the-path-of-a-file-at-changeset-without-using-the-workspace
The scenario he covers is sort of an edge case in which one user is modifying a file in their workspace, but another user has moved the file to another part of the component in their workspace. Obviously you want both workspaces to have the same reference to the same versionable (avoid an evil twin, using ClearCase-speak), but flexible enough so that users can move things around without impacting others.
In that sense you'd need a workspace/stream for context in order to scope to the correct versionable. Stream A may have that file in Component/src/foo, Stream B may have that same file in Component/src/bar. You don't want to lose version history between the two, even though both streams have the file in separate locations, so it makes sense that IBM would need something higher than any individual changeset to figure out the contextualized location with respect to a stream or workspace.
This was answered by a Jazz developer in another question:
https://jazz.net/forum/questions/103431/urgentfetch-the-the-path-of-a-file-at-changeset-without-using-the-workspace
The scenario he covers is sort of an edge case in which one user is modifying a file in their workspace, but another user has moved the file to another part of the component in their workspace. Obviously you want both workspaces to have the same reference to the same versionable (avoid an evil twin, using ClearCase-speak), but flexible enough so that users can move things around without impacting others.
In that sense you'd need a workspace/stream for context in order to scope to the correct versionable. Stream A may have that file in Component/src/foo, Stream B may have that same file in Component/src/bar. You don't want to lose version history between the two, even though both streams have the file in separate locations, so it makes sense that IBM would need something higher than any individual changeset to figure out the contextualized location with respect to a stream or workspace.