Jump to content

New files or folders committed with (name_conflict)_* prefixed


Recommended Posts


We have recently run into a weird bug where it appears some files and in one case a folder was submitted with (name_conflict)_ prefixed.

It only happened a handful of times and from what I can tell the files had their normal names when they were submitted, but in the repository they are suddenly prefixed with (name_conflict)_*.


In most cases I think it happened to new files being submitted, but we had one case where one developer was unable to rename the file, each time he committed the renamed file it would go back to (name_conlfict)_.


This happened in several of the latest releases of 5.4


So weird bug, difficult to reproduce, ill post again if i learn more.






Link to comment
Share on other sites

Hi Jonas,


let me explain when Plastic renames the files or directories in that certain way so we can think if it makes sense in your scenario or we can get more details from you.


The automatic rename operation is always done during a merge operation, keep in mind a merge operation is not only performed when you actively say "Merge from...." to plastic, it's also done when you checkin changes and some other guy has checked in changes at the same branch before you.


The automatic rename operation is done when Plastic finds that the file/dir name you want to checkin is already taken by other file/dir and the solution Plastic applies is renaming the one you checkin.


Can you check, using the changeset context menu option "Browse repository on this changeset" if another file/directory is submitted with the same name?


Can you also check if renaming the file that is rollbacked to "(name_conlfict)_...." to something like "thisIsAFileNameThatImSureIsNotTaken.extensionFile" works?

Link to comment
Share on other sites

I am having some trouble to see what actually happened in some of the cases. Some changes were undone via subtractive merge and now if i try to see the diff it just says "No content to compare". and i cant find any point where there are name conflicts in the repo. Strange.


But the last occurrence is there and it was the result of a merge.

In this case a folder with some files were added. 

After the merge the folder was prefixed with name_conflict. There is no sign of any other folder having been there, after the merge there is only that one folder.

The folder was renamed back to its original name and checkedin without any problems.


I wonder if this can be related to us using Unreal 4. It sometimes has exclusive locks on files, which that can really mess things up if plastic tries to update them.

Link to comment
Share on other sites



nop, I'm afraid Unreal 4 has nothing to do with this.


Another scenario, during the merge too, where the directory can be automatically renamed is when a recursive merge appears.





Maybe you can create a new branch from the old destination cset, retry the merge  and see if indeed it's a recursive merge.

Link to comment
Share on other sites

Hi! For the record, this happened to us as well, in a merge.


We had imported our repo with some active branches from SVN via Git into Plastic. Back in SVN, we had added a folder on main and merged this to one of the active branches.


Later, in Plastic, we merged back that active branch to main, resulting in a total replacement (delete+add) of the folder and a move of the folder-contents from the old to the new (identical) folder instance. (This is reported separately in support ticket 8301.) The reason for this is that info about the origin of the added folder is lost in the merge, since Git does not handle directories and Plastic GitSync fails to detect this situation as a folder-copy-add when analyzing the merge.


When we later merged from main to another branch (that was branched from main after the initial folder add but before the merge-back) we got the (name_conflict) renaming happening on the folder, due to a Changed/Deleted conflict.


Even though this folder has the same pathname and contents on both branches in the merge, Plastic sees them as two totally different folder-items once it has lost track of the initial connection between them. In our case this connection got lost in GitSync. It can also happen if an Add operation is Cherry-picked instead of Merged, potentially leading to an "item loaded twice" conflict in later merge. Read more (and vote for) this uservoice: http://plasticscm.uservoice.com/forums/15467-general/suggestions/3311147-possibility-to-merge-independently-added-files-dir

Link to comment
Share on other sites

Hello Goran,


yes this is a side-effect of the migration, as you said Git doesn't track directories and we do, during the repository import different directories ID were given to the "same" directory, I say "same" because for a human it's the same but not for the system.


So later the behavior it completely normal, that's how the system is designed to work when it finds this situation.

The cherry pick example you gave is also another scenario where it can occurs.

Link to comment
Share on other sites

Please note that this issue of "different directory IDs" is inherent in GitSync and could happen in normal GitSync scenarios, not just in an "import". There is no reason the directory should not be "same" in the GitSync system. Being "same" is what the Git user intended so it would be better if GitSync could be smarter and detect it as such. (The fact that dirs are not explicitly tracked in Git makes this harder but surely not impossible?)


Also, I personally think the automatic renaming during a name conflict could be handled more nicely. There is no dialog notifying the user that it happened, you have to discover it in the Pending Changes. Here, the user should be given an option to resolve this name-conflict by telling the system that the two directories should be considered the same item.

Link to comment
Share on other sites

Hi Goran,


yes it would be better to handle the directories as the same ones, but it's not straightforward for us to do it, I'm not saying it's impossible but it will take from us a good amount of resources.


On the other hand, if you give me an scenario, that I can reproduce regarding the automatically renamed directory we can think in a better resolution, maybe merging the directories id into a single one or something similar.

Link to comment
Share on other sites

  • 4 weeks later...

Hi Manu! I'm not sure I can easily come up with a scenario to reproduce. We are still getting these problems sometimes when merging, but they are caused by the above mentioned problems in GitSync during our migration from SVN. (Once we have merged all our migrated branches back into the main branch we expect these problems to go away, leaving only cherrypicked "item loaded twice" etc to worry about.)


Being able to merge directory IDs instead of automatic renaming would be super! I'm eagerly awaiting any improvement to the area of directory conflicts...

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...