I know how .private. files are created by Plastic due to private files of the same name already existing. But is there any way to disable this feature and allow the file to overwrite? Because I’ve run into a situation where I think this is more harmful than helpful. Particularly with Unity .meta files. Because he .private.0.meta file would already have the GUID that the new .meta file coming in would, and then Unity would give the .meta file coming from version control a NEW GUID, thus breaking stuff.
Hi, I’m afraid that this behavior is not currently customizable. Plastic by default doesn’t overwrite the paths on disk that are not under version control. Because if you overwrite any of these paths, the content of the file won’t be recovered (because they are not under source control).
Why would you have .meta files on disk that are not under source control and then when you update, there is a different version of that file in the repo so it’s renamed to .private? Note that if the file on disk content matches with the file in the repo, Plastic won’t rename it.
There are some options to clean the workspace and delete all the private/not under source control files: Git clean equivalent - General - Plastic SCM Community
I think it most often happens when plastic crashes, or there’s a particularly long-running operation and the user kills it because they think it locks up (unfortunately, it happens). Hence they might have source+meta files from a different changeset than plastic now thinks they are on.
Unfortunately, we want to delete all private files named .private., not all private files (because some off those actually need to be there). But for that I tell them to use del /s *.private.* in windows cmd. The problem is I already have to be helping them because they’ve fouled up so badly.
I understand about it not overwriting them because of recovery, but the alternative of the duplicate files is also undesirable.
But now that I’m thinking about it, it appends .private.0 to the very end, which would actually make Unity not pick it up as a .meta, so it’s okay.
Sorry for the confusion. I was working with a user to recover when plastic had decided her workspace was corrupt, and in recovering her work that’s how we wound up with all these private.0 files. At the time, I thought it was causing a recurring issue she had. But now I realize it was the other plastic bug which I have a ticket open with support on, where clicking Workspace Explorer > Update Workspace will sometimes convert Moved (renamed) files to Added files.
1 Like