Wolfram

Update: According to the Release Notes, this is fixed in 11.0.16.7806! 🥳

According to the Release Notes, this is fixed in 11.0.16.7806! 🥳

To prevent and/or not have to reset this for every single/new workspace: To disable the date filter for the "Branch Explorer": close the client, then edit %localappdata%/plastic4/branchexplorer.cfg , and change/add these lines in the [Default] section: display.options.start_date=633979567540000000 display.options.timesince=AGivenDate Unfortunately, I don't know of any functional default setting for the "Changesets" tab, and the "Set as default query" button does not work as expected (or is limited to a singular workspace/repository, which is rather unhelpful here).

If the default/global ignore.conf were to ignore itself, it would create the situation you described: any local ignore.conf's would no longer be "visible" to Plastic, so they would never be checked in, and each user could have his own, unsynced ignore.conf as a result. That's why the default ignore.conf EXCLUDES ignore.conf (=has that line preceded with a "!") from being ignored, so local ignore.conf's remain visible to Plastic, and can be committed, which is what you want.

It mostly depends on your move detection settings in the Plastic client, so play around with different settings there. But still Plastic will sometimes get confused, as it seems to compare file content ONLY, independent of the file name. So if you have two identical PNGs and move them to a different folder, the confusion shown in your screenshots may happen. When Plastic's detection fails, I generally undo the rename, and then move/rename these files in the Workspace explorer in Plastic (not the Windows Explorer, and not the Unity Editor), as it fully keeps track of all affected files. However, make sure you ALSO move/rename every associated .meta file along with it 8especially when renaming a folder - each folder also has its own .meta file).

It might be better to tackle the cause of these EOF inconsistencies, instead of trying to hide the symptoms. What I mean is, make sure that everyone working on the project uses the same EOF settings when editing files (namely "Windows"/"DOS" =CRLF vs. "Unix"=LF). These are usually settings in your source file editor (such as Rider), and note that there is also a Unity Editor setting for this (see image). So, agree on an EOF setting ("Windows" or "Unix"), make sure each team member's Unity Editor is configured accordingly (it's a local setting, not stored in the repository), and also make sure that the source file editor every team member is using adheres to that choice. Then, to fix your current situation for already existing files, use/find a tool that can convert one EOF type to another (most text editors should be able to do this - but usually only on a file-by-file basis, which can be tedious. However, there are CLI tools like dos2unix and unix2dos out there which can help), convert all your files, and commit these changes. Every other team member should then discard his local changes that consist only on EOF differences, then update to the newly committed version.

Just FYI, this functionality exists, and/but it is called "Subtractive merge", under the "Advanced merge" menu. It reverts changes from a particular changeset (or a range of them). If you do this often, it will clutter your branch explorer with lots of red merge links, though.

I fully agree that it is not a good idea for a tool and/or diff tool that focuses on source code files (as opposed to prose or something else) to use a non-literal (or even a proportional) font as default. => Plastic's default font for diff-/code view should be changed to a fixed/monospaced non-ligature literal font.

You can simply move your Workspace with a File Explorer to the new location, and then in Plastic "Create" a new workspace, giving the new path as destination. In that case, all local workspace information (=Workspace name, linked Repository, local states like Pending Changes, Home-Position, ...) will be retained (no matter what you selected in the "Create new workspace"-Window, only the path is important here), as the hidden .plastic folder was moved with it, and Plastic will re-interpret that info when "creating a new" workspace. The naming is indeed confusing, though.

Agreed in all points. I also LOVED the "View history as 2D revision tree" version, as it gives you a clear and familiar (=>Branch Explorer!) overview of the branching history of that file, in addition of conveniently showing the file diffs BELOW the history (as opposed to squished to the right of the "pretty" history list).

Under Rightclick=>"Advanced options", there is always the option "Move from this changeset to a different branch...". You can even move several changesets at once (=fixed range "selected changeset up until the end of the branch"), and even modify changesets in branches that have already been merged back (however, then you are forced to move them to a new branch created at the predecessor of the selected changeset). Granted, this feature is limited to moving these changesets to an EMPTY branch - but still, it does what you want, and you can then simply merge that new branch into your desired branch. These would both be cool features! Add to that the option that when deleting the changeset I'm currently on, the changes are not lost, but also put back into local/pending changes.

In the dot-menu on the right, select "Change editor font...", and choose for example "Lucida Console" or another monospace font, instead of the default "Cascadia Code".

We have encountered this problem in the past, whenever we have "long term branches" that keep merging to and fro from /main and/or other branches. Our (only) solution was to end these branches, merge them back as necessary, and then start new branches from /main (or whichever parent you need to). These branches will then be fine and no longer create empty changesets in the Xlink source repo, UNLESS you start merging or modifying Xlink assets in these branches/in the connected Xlink "client" repos, at which point the whole thing would start happening once again. So try to find a workflow that keeps the number of long-term branches to a minimum, i.e., keep your branches short (e.g., task-/ticket based etc.).

Any packages referenced/installed via Unity's PackageManager will have the necessary configuration info in /Packages/manifest.json , so as long as you don't have that file (or the parent folder) in ignore.conf or hidden_changes.conf or cloaked.conf, any changes you do in the PackageManager should update that file, which you then need to commit. This is true for regular Unity packages, for external packages (=scoped registries) such as OpenUPM, and for GitHub URLs. Local packages generally refer to absolute pathes on your local Workspace machine, so you'll need to take care that these are available on everyone's machine (however, you can edit manifest.json to make the references pathes relative). For embedded packages, make sure to NOT have /Packages and any embedded packages in that folder in your ignore.conf, and then commit your /Packages/com.my.embedded.package to your repo. Never put anything in /Library into version control. Never manually edit anything in /Library/PackageCache - it's exactly that: a (read-only) cahce, that can and will be overwritten at any time.

See also this thread for some more details and alternatives: