Why are Private.0 files created?

[Stephen Taylor]

Hi,

If I merge from a branch which has the same file in it that I also have locally but not added, then the file from the branch I am merging from takes precedence and my local file gets renamed to myfile.private.0. Why doesn't this just create an evil twin conflict like it does if my local file had been submitted to my branch? Or at least pop up a dialog to get you to choose which file you want. Creating a private.0 file is not a very intuitive way of explaining what has happened.

Cheers,

Stephen.

[calbzam]

Hi,

If you have a private file in your workspace with the same name, but it's not under source control, Plastic can't resolve any evil twin merge. The way Plastic handles it is renaming it to .private. This way, your local file is overwritten.

If Plastic was aware of this file, it will perform an evil-twin merge but if the file is private (not under source control), Plastic can't merge it.

Regards,

Carlos.

[Stephen Taylor]

Do you think it would it be better to bring up a different warning dialog though rather than silently create this private.0 file?

[calbzam]

Yes, I agree that we may need to include a better explanation regarding what's happening. Maybe a message explaining the user why we are renaming the files to .private.

Regards,

Carlos.

[Gardenfiend Games]

I just noticed some .private files in my project, and found this thread for how/why would have been created.

Makes sense - but does this mean that it is safe for me to delete all of these .private files? When I search my repo there are about 50 of them. Everything with my project is working great, so if the .private files are just "old copies" of the original local non-source-controlled files, I assume it would be okay to delete?

 

Edit: Immediately found this thread after making this post, with the exact answer😅: https://translate.google.com/translate?hl=en&sl=vi&u=https://forum.plasticscm.com/topic/22622-what-are-private0-files/&prev=search&pto=aue

[Xarbrough]

I also wondered this, so this means Plastic should only create .private files (or folders) if these are accidental duplicates not versioned before. However, in our case, I noticed some trouble this week on multiple workstations in our office: Artists and designers were complaining that their projects were completely broken and when I looked at them I found a dozen (one time even hundreds) of private files. After deleting them everything returned to normal. However, there's no way that our developers created all of these conflicts themselves. I asked them about those files and for all of them they said they would never work in this part of the project anyway etc.

So it looks like Gluon might be causing private files to be created in some specific situation that seems a little buggy. I can't reproduce this and there wasn't anything sticking out in the logs, but if anyone has an idea what could cause these files other than real conflicts (maybe when switching workspaces or something), I'd like to investigate this further.

[calbzam]

Hi @Xarbrough, could it pe possible that an update operation that was killed before it finished so the workspace had some files with aprtial content?

Plastic creates .private files when the update operation needs to download a file but there is already a local file with the same name on the same path.

Regards,

Carlos. 

[Xarbrough]

1 hour ago, calbzam said:

could it pe possible that an update operation that was killed before it finished

Usually not something our designers and artists do, they're more of the cautious type, but well that's good info anyway, I'll share it with the team to keep an eye out when updating and seeing any more .private files.