Stephen Taylor Posted February 6, 2019 Report Share Posted February 6, 2019 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. Link to comment Share on other sites More sharing options...
calbzam Posted February 6, 2019 Report Share Posted February 6, 2019 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. Link to comment Share on other sites More sharing options...
Stephen Taylor Posted February 27, 2019 Author Report Share Posted February 27, 2019 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. Link to comment Share on other sites More sharing options...
calbzam Posted February 28, 2019 Report Share Posted February 28, 2019 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. Link to comment Share on other sites More sharing options...
Stephen Taylor Posted April 1, 2019 Author Report Share Posted April 1, 2019 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. Link to comment Share on other sites More sharing options...
calbzam Posted April 2, 2019 Report Share Posted April 2, 2019 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. Link to comment Share on other sites More sharing options...
Stephen Taylor Posted April 9, 2019 Author Report Share Posted April 9, 2019 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. Link to comment Share on other sites More sharing options...
calbzam Posted April 11, 2019 Report Share Posted April 11, 2019 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.