Unexpected change/delete conflicts causing _name_conflict issues

[niraj]

I am merging from one branch into another. There are several files that say they were were deleted on the destination (workspace) and changed on the source. However, I can see those files in the folders on the destination, and I can see them when I use the Plastic SCM client to browse the changeset I'm in, so they haven't been deleted or removed from source control. Strangely, when I open the merge tab and click Choose Resolution Method, it says:
 

Quote

Source: Modified /FolderName/FileName

Destination: Deleted /FolderName

That implies that the entire folder has been deleted, but it hasn't and none of the other files in that folder are showing a conflict. I changed two of the files in that folder on a previous changeset of this branch. However, it's possible that the file that is showing the conflict is the only file in that folder that was changed on the source branch (which is the main branch) since they were last merged.

Since I don't understand why Plastic SCM is telling me that the file is deleted on the workspace (destination), I choose the change instead. When I do that, a discarded conflict warning appears at the bottom saying that "the item '/FolderName' has been renamed to '(name_conflict)_FolderName' because the path was already in use during the merge operation". 

The same thing happens for several files in multiple folders when i try to merge. Does anyone know what I'm doing wrong and how I can correct this merge?

[calbzam]

Hi,

We may need to arrange a GoToMeeting session to debug the issue. The key is understanding why the conflicts determined by Plastic doesn't fit with what you see in the different merge contributors. You can reach us at support@codicesoftware.com

Regards,

Carlos.

[niraj]

To those with a similar issue:

Carlos and I resolved the issue (thank you carlos). People were copying files from the main branch into the destination branch without merging. That made plastic think they were two separate files. The _name_conflict folder was being created because it couldn't figure out how to merge the two files. I am now manually merging the name conflict files (which are the source) with the files in their normal location (which are the destination). Then, the files will be merged and Plastic will understand the changes. The long term solution to this is to merge more often and not copy and paste files between branches.