Search the Community
Showing results for tags 'conflict'.
We have one serious issue here. I just find out that if somebody add a new file in one branch, cherry pick that changeset to a child branch and after some time he/she wants to merge from the second branch to the first one, the file cannot be merged! I knew already about an evil twin conflict and the inability of Plastic to solve this type of conflict by a merge. I thought that a workaround to this is to make sure to check-in a file in one branch only and cherry pick it to other branches if needed. Now, I see it is not always a solution. In the described case the problem is even hidden, because Plastic offers an option to View content of the item loaded twice only (which looks like there is only one version of the file, so no merge is actually needed) but this is possibly not the sole version of that file. There might be a different revision in the other branch. What user typically wants is to merge those two revisions, but he/she can't! I don't understand why. May you bring some light into this area? (My primary system is still Plastic 4.1, I haven't tried this in Plastic 5 yet.)
I'm familiar with other SCM but just learning how to use Plastic - specifically the Gluon frontend. During our tests we engineered a situation where a file had been checked-out and changed by A and then deleted by B. As expected this leads to a conflict in Gluon when A attempts to check-in the changed file. What are the options allowed by Gluon to solve this conflict? We are able to lose the local changes and have the file remain deleted but is it possible to override the deletion with the local content changes and if so how?