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

[Amimoller]

Hi,

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.

 

 

 

Cheers

Jonas

[manu]

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?

[Amimoller]

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.

[manu]

Hi!

 

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.

 

http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html

http://codicesoftware.blogspot.com/2012/01/more-on-recursive-merge-strategy.html

 

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

[manu]

Of course tell me what do you find.

 

If you can repeat the merge and you get the same behavior we can schedule an online meeting to review it.

 

Thanks.

[Amimoller]

I tried all the ways i could think of to do the merge again, but I could never get the same error.

We also haven't had the problem since.

 

Ill post if it happens again.

[gweronimo]

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

[manu]

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.

[gweronimo]

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.

[manu]

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.

[gweronimo]

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...

[manu]

Hi Goran,

 

Ok, if you see the issue happening for a branch not involved in the migration process let me know it. We can get connected and repeat the merge in order to debug with it's happening.