Replacing component in workspace is resulting in some merge conflicts
Thanks!
Accepted answer
1. Baselines: Specify a set of changes that make the state/content of the component
2 Stream: A set of components, Each component specifies a set of changes that make up the state/content of the component
3. Repository workspace: "Personal Stream"
If you have a stream and a repository workspace pointing at each other and you replace the baseline of a component in one of them, but not the other, it is absolutely possible and to be expected to get conflicts and non trivial merges. This basically only depends on how the different states evolved from each other.
If you use distributed SCM, there is no need to only work with one repository workspace and stream. The required history is going to be replicated even if you use a new repository workspace and stream.
Comments
Thanks, what I just figured out is I should be replacing the baselines in the stream instead of the workspace. What I had been looking at led me to believe that the entire component history was not being copied over to the new repo and I was making this more complicated than it was. Thanks!
One other answer
What kinds of conflicts you get basically only depends on the difference of the changes that have been done to the component in the baselines. Lets say you developed for a bug fix version of your software on stream 1 and do some changes to the file A in component compA. You create a baseline BL1A. In a different stream S2 you have a repository workspace RW2 and develop changing the file A in component compA as well. Same line as above. You create baseline BL2A. Now you replace the baseline BL2A in component compA with BL1A. You get a non trivial conflict between stream and workspace. This is regarless of where you replace the baseline, in the stream S2 or the workspace RW2.
This is not a tool issue as far as I can say.
Comments
I probably wasn't clear enough that I am replacing baseline used in my workspace. I had been thinking that what I put in my workspace will always be seen as what needs to be added or set in the stream that it flows with. Does this change anything in your answer?
The bottom line is that I want to make my workspace be using components at a now different baseline. After I change the baseline used in my workspace, incoming, outgoing, and unresolved merge conflicts appear. The merge conflicts are under unresolved, and does that also indicate they are conflicts in my sandbox? I could just accept the incoming, deliver outgoing change sets and then reload my sandbox. Although I am also wondering if I need to accept before deliver or is that just a spaghetti mess of order that change sets should
And one more tidbit of info. I am doing this as part of a code history copy to another separate repository (different jts and authentication source). I started with a baseline of 11.4. Got that history copied over. Now I am trying to not create a duplicate component, by starting with 11.4 and adding the changes between 11.4 and 11.5 by pointing my migration workspace to 11.5 now. That is where these conflicts are coming in.