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

Hi,

It seems we are getting this fairly often. I'm sure if it is from exactly the same scenario you describe above though.

Is there any fix in the works for this?

It seems to me that since the file is cloaked (i.e shouldn't be there) you should be able to determine that we don't need to rename any files?

At the very least you should get a dialog warning you of a name conflict rather than just renaming the file, as the out-come is that the original file is getting lost. Which file does it rename?  The one from the server or your local file?

Cheers,

Stephen.

Share this post


Link to post
Share on other sites

We already have a task (not yet scheduled) to study and improve the behavior in my previous example. Anyway, it shouldn't be a common scenario and we may need to review your workflow in detail.

It involves you to run a merge that includes paths cloaked in your workspace and also then run additional merge from another branch that also involves conflicts in this sale cloaked path.

We can focus on one of your cases and determine if it's the same or a different one and how we can improve the workflow.

In my previous example, the downloaded file is renamed to "name_conflict".

Regards,

Carlos.

Share this post


Link to post
Share on other sites

Maybe as a quick workaround for this problem you could you make sure a merge deletes any cloaked files on your machine if you have a cloaked.conf?

This has already been shown to be a good work around as on a similar support tracker we have:

https://plasticscmsupport.zendesk.com/hc/en-us/requests/16662

If this was done automatically it would greatly help us as we have had to turn off cloaking at the moment due to it is causing too many issues.

 

Share this post


Link to post
Share on other sites

Yes, we should find a solution for this scenario. We have internal tasks for both the ticket you are referring and also for the scenario I mention above so hopefully we will have good news soon.

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