It's all about the answers!

Ask a question

Replacing component in workspace is resulting in some merge conflicts

Vince Thyng (13723553) | asked Jun 08 '16, 11:27 p.m.
I am replacing the baseline of a component to a different one and it is giving me a non trivial merge conflict.  I am now thinking the files may have different uuids even though they have the same name, and I will go check that now.  If anyone happens to know of another way this can be caused, please let me know.


Accepted answer

permanent link
Ralph Schoon (63.0k33645) | answered Jun 14 '16, 1:53 a.m.
I think you don't really understand how SCM works, at least not RTC SCM, what you are looking at and what to expect.

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.
Vince Thyng selected this answer as the correct answer

Vince Thyng commented Jun 14 '16, 4:57 p.m.

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

permanent link
Ralph Schoon (63.0k33645) | answered Jun 09 '16, 3:12 a.m.
If you replace the baseline of a component with another, you change the content of said component. If you have a flow set up between a stream and a workspace and do the replace in any one of them, you can create the situation that the same files have been changed concurrently and you can also create any other kind of non trivial merge conflicts.

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.

Vince Thyng commented Jun 13 '16, 1:37 p.m.

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?

Vince Thyng commented Jun 13 '16, 2:21 p.m.

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

Vince Thyng commented Jun 13 '16, 2:46 p.m.

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.

Your answer

Register or to post your answer.