Jump to content
Sign in to follow this  
Stephen Taylor

name_conflict files added during merge

Recommended Posts

On merging from our main branch into a user branch the changelist lists some files with name_conflict in the file name.

I've used 'Browse repository in this changeset' to look at the contents of the user branch before merging from main and the files in question don't already exist.

I also look at the changeset in main and they are named correctly.

After the merge and submit to the user branch the files have been changed to have name_conflict in them and the originals are no longer present.

The name_conflict files are listed under Added (files added in the merge source)

My question is how is this possible?

I tried creating another changeset from our user branch before the merge was done and re did the merge to try and reproduce this issue. This time it was all fine, so I'm not sure what went wrong the first time?

I have explored a few possibly explanations.

1. What happens if the file was already submitted to the other branch (which it wasn't). In this case I get an evil twin conflict.

2. What happens if the files that I would be getting in the merge were already on my machine but not submitted? I tried this with a txt file and I didn't get any warning conflict or renaming to name_conflict. What did happen though was the file I had locally disappeared in the merge and the contents were lost. When I submitted the merge the file contained what ever was coming down from main. There was .txt.private.0 file left on my machine though which contained the local txt I would have wanted to merge. So this also went wrong but in a different way.

Cheers,

Stephen.

Share this post


Link to post
Share on other sites

Hi,

This "name_conflict" files appear when a merge operation needs to download a specific file but it already exists in your workspace. It could happen for instance if you already had a private file with the same name on this path. 

Do you have "cloaked.conf" rules? There are also some scenarios it could also happen with cloaked files.

Regards,

Carlos.

 

Share this post


Link to post
Share on other sites

Hi,

We are using a cloaked.conf. If these files are cloaked by someone can you explain how this name_conflict might arise please?

I know that even cloaked files can get download for client side comparison reasons I'm not fully aware off. Could this explain it in some way?

Cheers,

Stephen.

Share this post


Link to post
Share on other sites

Let me show you an example (although it shouldn't be a  very common scenario):

1. You have a "cloaked.conf" where you include "myproject/binaries".

2. A different developer adds  "myproject /binaries/asset_1.bin" in the "/main" branch.

3. I'm working in the "/main/task001" branch and run a merge from "/main". At this point "myproject /binaries/asset_.bin" is in my workspace but marked as cloaked.

4. I switch to "/main/task002" ( " myproject /binaries/asset_1.bin" is still as cloaked in my workspace).

5. I run a merge from "/main" to "/main/task002". The merge tries to download the  "myproject /binaries/asset_1" file. The problem is this file was already cloaked in your workspace so Plastic renames to "name_conflict_....".

Regards,

Carlos.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...