Jashan Chittesh

Sorry for not getting back to you earlier - after all the troubles with this, we eventually gave up and have kept using Google Drive for the art assets. But it's good to know that this should now be fixed, so we might give it another try at some later point in time.

Another issue that I just saw: When removing the folder from the cloaked.conf file, instead of downloading the files next time I refresh in Plastic, the folder is shown as deleted. I can see why this happens and I can get what I want by using Undo ... but it's not a great UX because there is quite a risk that someone accidentally checks in deleting the art folder. The way we'd use this is to have cloaked.conf having the art folder included by default, so the first thing an artist would do when creating a new workspace is get the workspace, remove that one line from cloaked.conf, then update. It looks like again, the workaround would be to get the workspace, remove the line from cloaked.conf, then "Switch workspace to this branch" even though we already are on that branch.

I have just tried using the cloaked.conf approach (which seems to be exactly what we needed all along) and it does seem to work well as long as there are no changes in the cloaked files. In other words, once I have set this up, Plastic doesn't download any of the files in the folder that I have added to cloaked.conf. I can switch branches without getting those files, so that's all perfect and as expected. But as soon as I make a change to one of the files in that folder, Plastic downloads that file the next time I use Update workspace (in pending changes => "1 new changeset available" => View => Update workspace). I have also tried a changeset with changes both in cloaked and non-cloaked folders but I still get the files from the cloaked-folder that way, unfortunately. I can work around that by using "Switch workspace to this branch" in the branch explorer instead but this basically means that nobody can use Update workspace if we want to use this.

Hi, working in Plastic, we use centralized for sake of simplicity. It looks like cloaked.conf actually does what we need, thank you! Maybe you could mention that file in the Git sparse checkouts and partial clones blog posting because that's where people looking for that functionality will usually end up.

Hi Carlos, I'm sorry but that doesn't even address our use case. Our issue isn't that artists need sparse checkout - because they actually do need to work in the Unity project. Our issue is that we don't want the rest of the team to have to download each binary art update when artists work on their source files. Artists get everything, the rest of the team only gets the Unity project because they don't need to work on the art files (most of the time, some of us may occasionally want those files). So, in our case, everyone would have to use Gluon except for the artists, lol. I'm honestly a little shocked that something this basic doesn't seem to be implemented, especially when there's a dedicated blog posting claiming that Plastic does it all better than Git when Git sparse checkout does exactly what we need and Plastic apparently just can't do it at all (except with rather cumbersome hacks that require changing our workflows). Sunny regards, Jashan

I have read Git sparse checkouts and partial clones, nodata: the secret sauce of lighter clones, Xlinks: Reusable components and Xlinks Guide ... but I'm afraid none of these have answered my question in a satisfying manner. What we're trying to solve: We have a Unity project repository (centralized, so no replicas or anything distributed and we'd prefer to keep it that way) and want to add a folder for the art team. For the art team, this needs to be one workspace / repository with everything because we don't want to make things complicated for them by requiring two different workspaces or even worse, two different repositories. Some other team members may want to opt in to the art-folder but by default, they don't want to get those updates. So this very much sounds like what Git sparse checkouts and partial clones wants to offer (and it is in fact trivial to set up with Git sparse checkouts) - except we don't care about changesets at all for this use case. We only want to say "include this folder for me" or "ignore this folder for me" (basically, a workspace setting that locally ignores folders and pretends that they don't exist in the repository). So Xlinks kind of looked like it may solve the issue, even if in a more complicated way than we'd like: We could make a UnityAndArt repository, Xlink into the Unity repository from there and also have the art folder in there. Most people would just use the Unity repository, art would use UnityAndArt. My concern is that Xlinks seem to be designed to link to a specific changeset in a different repository (which makes sense for the use case it was designed for) but our workflow needs to be "Get latest for everything" or "switch to that other branch of everything" or "switch to that specific changeset for everything" (again, we don't want to have art to jump through additional hoops). In other words, we can't have separate changeset histories and from what I've seen, this doesn't seem to be possible with Xlinks because it's different repositories (because it's actually designed for a different use case). Even worse: It looks like every time art would want to change the version of the Unity project, they'd have to change the Xlink, which is too cumbersome to work. In Git sparse checkouts and partial clones, there's one interesting paragraph: While from what I understand, using this (if it is already implemented) would require switching over to a distributed model, it could solve the actual use case we have in a comparatively straightforward manner. That posting is more than 2 years old, so maybe we're lucky? Or is there another way to solve this in an easy-to-use way?

Hi Héber, we do occasionally revert that file to previous versions, yeah. But the last commit that I see on that branch was a regular one. I was at first confused about what you meant by "It should be the one in bold" because the alpha UI doesn't bold changesets in the history (regardless of dark or light theme). But I did find it with the legacy UI (also, I just saw that the changeset of the file is also shown in the Workspace Explorer, so that would be the way to find out in the alpha UI, I guess) ... and: Turns out the active version on that branch was one from a child branch of this current branch that we hadn't merged back into this branch (so that was definitely not the correct version - there's no way I can think of how that version became the active one on my branch). Now I have reverted to the last version on this current branch and after that, it shows the commit I just made as active one. It's really weird that it showed the version from the other branch instead of the commit (if we even did revert something there in this case - it certainly doesn't look like that from the history). And ... that fixed it! 🙂 Thank you! Sunny regards, Jashan

Hi, I'm getting a very annoying error when merging to a specific branch: I have double-checked (several times) that the workspace is clean, i.e. there are no changes on the workspace before starting the merge. That particular file behaves normally when I apply changes, i.e. I can make changes to the file, undo those changes. There are no changes on that file compared to the changeset that I'm working on (or at least none that would show up but I have confirmed that when there are changes, they do show up). And yet, when I merge from another branch, into a clean (i.e. no changes) workspace, this specific file gives me said error: I have not changed branch on that workspace in a long time. 26075 is the last changeset on this branch (that I'm currently on and merging to). So before I started the merge, there was no change on that file. All changes currently on that file are due to the merge (there was a merge conflict but nothing particularly complicated, could easily be resolved with the merge tool). When I try to undo only that specific file (as the dialog says I should), it obviously doesn't work because this is a merge and Plastic can't do a partial merges. When I undo everything and retry the merge, I end up in the same situation. Here are my "What to show" settings (btw, I have tried this both the the non-alpha and alpha versions of Plastic): Sunny regards, Jashan

Sadly, this is still an issue in 2022 and I can't believe it. Plastic "matched" two files that have nothing to do with each other. One is a meta-file that Unity deleted because the asset no longer exists (it's a Unity package asset, not even a prefab). The other is the meta-file of a new prefab. Why don't I have a context-menu that tells Plastic "no, this is not a move"? This specific "move that wasn't a move" is particularly annoying because if I commit this, and someone else commits the deletion of the file that Unity deleted (which needs to be done), it will delete my prefab-meta file, breaking a lot of things really badly. The thing that's really annoying about this is that when I turn off move detection, this changes ... nothing. It still shows this nonsense move that is no move. Even when I disable move detection, close Plastic, re-open Plastic (and of course, I have tried refreshing a few times): I had even tried re-adding the old meta-file. But then, Plastic thinks "oh, there's a new file". So it looks like what I need to do is make a safe copy of my new prefab meta-file, undo the change, restore the safe copy (yeah, that did "solve" this for me, this time). This is not the first time Plastic destroys productivity for us. I have tried both, the legacy Plastic and the alpha. Same issue. I'm a few versions behind (11.0.16.6787) and looks like there's no "check for updates" button anywhere so unless I clicked on the tip when it showed up, I need to download and re-install via the Website. But even after that: Same issue with the current version (11.0.16.6949).

I also just ran into this. And it gave me a real headache. Until I switched off file move detection. Then, I could commit without any issues. Looks like the file move detection sometimes just doesn't really do the right thing and confuses itself.

I currently need to isolate an issue and to do that, I need to move back and forth in history, i.e. I need to go to specific changesets. Obviously, this can be done via the branch explorer by right-clicking a changeset and using "Switch workspace to this changeset". The problem with this is that it only works when there are no pending changes. So I basically need to shelve relevant changes (of which I have a few), undo all changes, then switch to the desired changeset, then run some processing to get back to a state where I can actually create a build (that's project specific, obviously - but that's how this project is set up). Plastic has this nice feature to "Update workspace" to head. Is there a way to only advance a specific number of changesets with this? That would at least let me go forward in time conveniently. Or, what I'd actually need: Move forward and backwards one changeset at a time on the current branch. Is that possible?

I have just downloaded PlasticSCM-10.0.16.5362-windows-cloud-installer.exe via the update link from the PlasticSCM client (https://www.plasticscm.com/download/10.0.16.5362/plasticscm/windows/cloudedition) but no matter what I try, Windows won't let me install this. Previous installations worked without a problem (I'm currently four versions behind, EDIT: I just double-checked with the 9.0.16.528 installer and that still works without problem). Also, any other installers that I have tried worked without any issues. I have already tried disabling Windows smartscreen and redownloading the installer. I also tried running the installer as administrator but same result. The issue seems to be "Publisher: Unknown". In Properties / Digital Signatures it says "Name of signer: Codice Software SL" with a timestamp from April 21st. This is on Windows 10 Pro, 10.0.19042 Build 19042.

Ah, cool, that sounds good.

Hi Carlos, thanks for getting back to me. I delete the file in the Unity editor and it's almost immediately recreated, essentially doing (almost) the same thing as when the system overwrites it - except it creates a cleaner version of the file. It may be that the Unity Plastic integration sends the "the file got deleted" to Plastic SCM, so one thing I could probably try is deleting the file via file explorer instead. There are quite few situations where you want to delete a whole folder with all its files, just to restore the whole thing with a new version, e.g. when updating Asset Store packages in the project. That's another case where deleting/recreating files in the version control system is complete nonsense and makes it impossible to properly track the changes that occurred in the update. I'm not aware of any cases where delete / recreate in version control is useful. Sunny regards, Jashan

We have a file that gets automatically generated but of which we also need to track the changes (this is a specific case where the changes in the generated file are actually interesting). Usually, the file simply gets overwritten during recreation. But we found out that over time, this keeps stuff in the file that shouldn't be there. So we deleted and recreated it. Unfortunately, Plastic seems to try to be smart about this, recognizes that the file was deleted and recreated, and puts it into both, "Deleted items" and "Added and private items". Very unfortunately, the result is that we lose the history, which is the whole point of using version control for this file in first place. I have tried using cm mv to make Plastic understand that hey, I want continuity of this file but it complains that I can't move a file to itself, which I can agree with. So how can I make Plastic detect the actual changes in the file instead of deleting / recreating it and wiping the history? Btw, this is a text file and marked as such.