Wolfram
-
Posts
141 -
Joined
-
Last visited
-
Days Won
12
Posts posted by Wolfram
-
-
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=AGivenDateUnfortunately, 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.
-
1
-
-
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.
-
1
-
-
On 1/18/2023 at 8:43 PM, Marc S said:
or if not possible, making a new changeset with the previous data
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.
-
1
-
-
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.
-
2
-
-
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.
-
1
-
-
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).
-
1
-
-
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.
20 hours ago, Marc S said:It's not possible to copy that changeset into a shelve to remake it on the right branch and it's not possible to revert a changeset to local changes.
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".
-
1
-
-
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.
-
1
-
-
See also this thread for some more details and alternatives:
-
Yes, we split up our Framework into thematically useful modules, and created individual packages from each.
If you managed to create the general package structure once, it is quite simple to work with it, and it is really comfortable to use Unity's PackageManager to include whatever modules you need into your projects. This includes being able to choose an explicit version of your package (as opposed to having to always using the most current one).
But as I said, for the UPM packages you need some place to host them - either OpenUPM or similar (but this would expose your code to be publicly accessible, which is probably not what you want), or running a local package a.k.a registry server (such as Verdaccio, which is not very complicated to set up).
Concerning your repository question - you're correct that read-only Xlinks are the way to go if you only want to include a specific folder (and you'll have to use the CLI to create such an Xlink, it can't be done via the GUI). However, it complicates things if you want to regularly/often make changes to your framework from within such a referencing project (as opposed to making the changes in the original Xlink-host repository itself).
What we did in the past for our Xlink repo was not to create it from a full Unity project, but just for a single directory in an otherwise empty local project (for example, create an empty Unity project, copy your initial framework source to /Assets/Plugins/MyFramework (or wherever you want it), and then create a new Plastic repository for just this one folder. This way you can keep referencing that whole repository as your writeable Xlink target.
Additionally, in that Xlink repository we then created individual, long-term "project branches" for each project that wants to reference to it via writable Xlink. This way, each project can "locally" modify stuff on its Xlink branch, without messing with the global/main framework code (and therefore all other projects using it). Then, from time to time, your framework maintainer can go through the Xlink source repo, and check all incoming changes from each project, and decide whether these changes should be integrated into the /main branch (preferrably using Plastic's Cherrypicking feature, so that you only integrate the changes you need, but can keep other changes local to the project branches.
-
2
-
-
Xlinks are what we used for this for many years. They have many advantages, for example each project using the linked codebase can even have its own local changes, and for writable Xlinks you could even extend your codebase from within each project, and then integrate these changes (or just the relevant parts from them, using cherrypicking) individually from within the Xlink repo.
However, a while ago we switched to Custom Unity Packages for most of our projects. These are especially useful if your individual projects don't need (or shouldn't!) make changes in the codebase. The setup is a bit more complex, though, as you'll either need your own package server, or use a (publicly accessible...) server such as https://openupm.com/ .
Here is a bit more info on how to convert your codebase into a custom Unity package for the Package Manager: https://docs.unity3d.com/Manual/CustomPackages.html
-
1
-
-
It could be that the "read-only access" feature was removed a while ago, and/or maybe these users are now actually blocking a license. For example, I haven't been able to add read-only users for a while now on our server.
Do you perhaps have 14 configured read-only users?
-
On 10/5/2022 at 6:19 PM, Christian Rieß said:
I tried what you did, and I managed to install the plasticscm-client-core package. But that does not seem to give me any GUI interface. Can you maybe post a step-by-step guide what exactly you did to achieve this? I am currently stuck with the command line interface and it is not really working out for me...
You'll need to also install plasticscm-client-gui for the gui to work. Or simply install plasticscm-client-complete instead, which will take care of everything.
After installing, you can launch the gui client with "plasticgui".-
1
-
-
Any update on this?
See also -
In the rest of the "cm li" output, how many users exactly are listed as "ACTIVE", and are there any users with neither "ACTIVE" nor "INACTIVE (Not licensed)"?
-
Oooh, I just discovered a workaround that gives you the best of both worlds! Full color circles per user, but for "specially" highlighted changesets (such as the currently selected, search results, etc.) you see most of the icon in the special color, BUT still see the user's color on the left.
You can activate this hidden feature by ENABLING the "By replication source" coloring, but then DISABLING all listed servers. See screenshots.
This way, you even get an additional visual info: "if the color sliver on the left is visible, this means that this changeset is currently highlighted differently for a specific reason (such as, being selected)", and therefore no more confusion whether a certain color refers to a user or a selection.
-
A single color for a selected changeset would not be enough: As you can see in my screenshot, there are at least THREE distinct variants that a changeset can be marked, and there is another color that's visible when TWO changesets are selected.
Reserving colors for all these would severely limit the options for color-by-user, and it will still happen quite often that a user color is too close to such a predetermined color.
Using the labels instead would be a large change, and would require implementing a completely new paradigm on how to depict labels (which also can have different colors, BTW - a feature we also use).
The workaround of disabling the replication source coloring gives you the best of both worlds - showing BOTH informations simultaneously, without the danger of cofusing any colors.
However, I do agree that the current user color sliver is quite small, it might help if the split is 50:50. Or alternatively, as the changeset icon consists of an inner circle PLUS an outer ring, the color of the outer ring could be used for all selection/highlighting styles (but this might be hard to notice, as that ring is very thin).
-
As the whole document is highlighted, I assume that the line ending/file encoding changed. Therefore, it gets confused by trying to diff every single line, without checking for minimal differences. So for example, for line number 19, it is comparing the left line "Join the LuaMachine Discord" with the right "## Discord Channel", and therefore finds the match "Discord".
Disable line ending/encoding comparison in the "three-dot-menu" on the right, by choosing one of the "Ignore EOLs" options.
-
1
-
-
17 hours ago, Francois Bertrand said:
turn OFF "color by replication source"
Ah, thanks! I never checked there, because I never explicitly enabled it, and I also assumed they were mutually exclusive.
But in this case, turning that option ON would also resolve YOUR problem (unless you really need the feature to multi-color different replication sources in the same repository), as then you can combine the user colors with the regular highlighting colors:
Hide/disable license warning?
in Installation and configuration
Posted
Update: According to the Release Notes, this is fixed in 11.0.16.7806! 🥳