Wolfram

It is great that the custom user colors (as defined in branchexplorerusercolors.conf, and configurable via BranchExplorer=>ChangesetColors) are now available in the new PlasticX GUI as well! I also like the fact that users get assigned "random-but-specific" default colors, depending on their user name, and that these default colors can then be modified to custom colors via the menu above. This is a vital feature for us, as the random colors are often indistinguishable in our team of about 15 users. However, currently there is an inconsistency where the custom colors are used for the changeset color tag in the Branch Explorer (see image 3) - but the "original" random user color is still used for all other visualizations, like the changeset mouse-over (see image 2), or the history view, and so on. This is quite confusing, as now the user has TWO colors associated with him. This seems like a bug. So instead, once a user color has been customized, that color should be used in ALL places where a user-specific color is shown. It would be helpful if you could fix this. 🙂 Cheers, Wolfram

I'm curious how these "full circle" user colors are enabled/disabled. For me, I only see the "color slabs" on the left side - which I like more, and it would also make the problem described here obsolete:

Are there plans to re-integrate this into the "changeset diff" window? Currently it is quite tedious if you want to access the history of such a file (=remember the file name, switch to the workspace explorer, search the file, confirm, then show the history...) 😕 Cheers! Wolfram

There was a very vital keyboard shortcut, ctrl-n/m, to go to the next/previous difference in the diff window (Plastic-Legacy-GUI, Windows). For the new PlasticX GUI, these shortcuts no longer work (and I didn't find any other key combinations that did this), so you are forced to use your mouse and click the arrow buttons, which is very inconvenient. Could you please add keyboard shortcuts for this? It would be very helpful! Thanks! Cheers, Wolfram

The PlasticX GUI has a license expiration warning that the old GUI did not have. We have a company-wide, sysadmin-maintained, auto-renewing subscription license, so none of our users EVER need to care about this, and even if they did, there is nothing they can do about it - only the sysadmin can. Nonetheless, that bright-red error bar now sits permanently (for at least the whole day?) on top, it can neither be closed, nor dismissed, which is very confusing and distracting to the users. So is there an option to disable this license check/warning, and if not could you please add a configuration for that, or at the very least make it dismissable? Thanks a lot! 🙂 (PlasticX 11.0.16.7649, Windows)

Well, you still haven't told us what EXACTLY you mean by "freshly imported project". How? From where? Using which tool? As I mentioned above, files were deleted in your workspace more than two months ago. WHAT KIND of files, and WHAT actions did you perform, either in Unity, or the external Plastic GUI Client. HOW did you create this workspace. etc. We will be unable to help you unless you provide sufficient information about what your situation is, and which exact steps you took that lead to your problematic workspace.

Also, your screenshot is definitely NOT a "freshly imported project". Files got deleted from that particular workspace over two months ago, and files were modifier multiple times within the last few days. So when you say "freshly imported project", what do you actually mean by that? Did you COPY that workspace from somewhere else, or extracted it from a .zip somebody gave you? (As opposed to CREATING a new workspace from within plastic, and then updating that - which is the normal workflow, and will not create any local changes by itself)

What kind of changes, what kind of files, and what pathes are affected? Please give some examples. For example, "all *.mat files", or "all files in /Library", or similar.

Thank you for the files, and the additional info. The .meta files seem normal, and also your /ignore.conf doesn't contain any incorrect or weird entries that would cause .meta files to be handled incorrectly. I am assuming you are using the PlasticSCM Cloud server solution provided together with Unity, as opposed to a local PlasticSCM server or something? In that case, it will not be possible for users to access the server log files. Unfortunately, I therefore can't help you any further with your issue. So you'll have to hope that someone from PlasticSCM responds to this thread, or you can try contacting their support directly via https://www.plasticscm.com/support Good luck!

Please attach one of the affected .meta files, so we can check the actual content (the '?' could mean any non-printable character). If your project has the files /ignore.conf or /hidden_changes.conf, please also attach them. When looking at the broken workpace on your laptop with the Windows Explorer (or similar), do you see files like "*.meta.private.0" besides the regular "*.meta" files? Can you verify in the Plastic WebUI that the .meta files are indeed in the repository?

Indeed, the shell pipe can be avoided, and the command can be abbreviated to: cm find "changeset order by changesetid desc limit 1" --format={changesetid} --nototal , which makes it even independent of when the last checkin was made.

But it may not return the branch name at all, if the selector is on a changeset (for example, you right-clicked on a changeset (instead of the branch) and did a "Switch workspace to..."). Note that IF (and only if) the selector is on a changeset, "cm showselector" does print the associated cs number as well.

Ah, thanks for the answer! I did discover the "find changeset" command, but wasn't aware of the additional formatting options - until now I was using complicated string processing to get to the correct line from its output, but these options are quite helpful! Also, it seems with newer server versions, there are now also additional parameters for "find", such as "limit <x>" and "order by changeset asc", which should help to get rid of that additional "tail pipe" (hehe) - which is helpful, as the "tail" command is not available in a normal Windoze CMD shell. And as we're mainly working with Unity Windows, we need to make C# Process()/system calls to "cm" that windows actually understands. Or is there a better way to get info from Plastic and/or "cm" from within Unity? (except the UnityEditor.VersionControl classes (which are essentially undocumented, and I couldn't get them to work with Plastic), and except the great REST-API via "cm api" (but this would require our users to always launch "cm api" first). (also, our Plastic server is still on an old version that doesn't support the "limit" parameter, will report back after we upgraded it.)

NVM, was answered here:

Hiho. Is there a method to simply show the name of the current branch via the "cm" tool? Even reading through several documentations and help files I didn't find one. The command "cm status --head" or "cm status --header" does not necessarily show the branch name, it often just shows the changeset number instead. The command "cm find branch" shows ALL branches, and I don't think I can create an "objectspec" that refers to the current state/changeset. Which is kind of curious, as commands like "cm update" ALWAYS refer to the current branch, so there should be a way to figure out which branch that is... Cheers, Wolfram

Any ideas for this? It would really help for automation processes.

Rafael's link has all the info, see especially the section "Merge types". In short, "destination" is ALWAYS the...well, the destination(-branch) of your merge, the branch you are merging TO. This doesn't necessarily have to be your current workspace! With the "old"/standard merge function "Merge from this branch...", "destination" *is* your current branch (including all Pending Changes). With the newer feature "Merge from this branch to...", you can merge from any branch to any other, and neither needs to be your current branch. Again, the branch you are merging TO is the "destination".

Achtually, I just noticed this myself: you only need to double-click one changeset. This opens the separate comparison window. Then, clicking on any changeset in the branch explorer will update that window, so it not only shows you which files have beend changed, but you can also directly access their diffs. (however, this trick only works if you only have ONE "Comparison" window open - with more than one, they will not update themselves)

I simply double-click on a changeset in the branch explorer, so I get a separate compare/diff window with all the changes and affected files of that particular changeset. It is also relatively easy and fast to "double-click" your way through different changesets this way. However, if you are unsure which changeset contains a certain change you are looking for, I suggest you force your users to use better commit comments, as they are supposed to help you figure out what happened in a changeset, without reading through all the source code diffs 😉

I am looking for a method to update a workspace to the latest changeset vla CLI - regardless of on which branch I am, or on which branch that latest changeset is. Just the highest cs number (or the cs with the youngest timestamp). I have tried cm update --last --forced --verbose <wk_name> and similar, but they are apparently all restricted to the current branch I am on. I also haven't found a combination of "cm status" parameters to figure out that cs number, as it also seems to refer to the current branch only. The reason behind this, I'd like to have an automatically maintained (=kept up-to-date) overview of the current state of all Assets of ALL repositories (for example, to quickly check which repository is currently using which Asset). If this is not possible directly, is there a method to figure out on which branch the latest cs is? Then I would be able to run a command to switch to that particular branch, and then do a regular update. Thanks!

Well, we did not have a global filetypes.conf before the update, as the txt/binary detection was working very well then, even for the "uncommon" file extensions *.asset, *.unity, *.prefab used by Unity After the upgrade we did add a global filetypes.conf in the correct location, and it is also being correctly downloaded by the clients. The contents are: # Fichero de extensiones de Plastic SCM. Sintaxis: <expresión>:<tipo>. # Expresiones válidas son: .cpp, myfile.cpp ... Se pueden usar metacaracteres (*, ?) # El tipo puede ser 'txt' o 'bin'. # Ejemplos: # .cpp:txt # .jpg:bin *.anim:txt *.asset:txt *.cginc:txt *.controller:txt *.cs:txt *.csv:txt *.json:txt *.mask:txt *.mat:txt *.meta:txt *.md:txt *.prefab:txt *.preset:txt *.py:txt *.shader:txt *.unity:txt *.xml:txt This may have improved the detection for associated files under version control (I'm not sure, I don't have any negative feedback from this from our team at the moment) - but that file is apparently ignored for "Private" files, or even files already marked as "Added" but not yet checked in. This makes it quite difficult to review your changes before checking them in - especially if it also fails for definitely readable text files such as *.cs or *.json.

Well, we often get changesets for already existing assets which are by themselves NOT modified in that changeset, but the FS permission changes from "NOT_DEFINED" to [...] are still being committed. It is not a bug or causes any problems - but it kindof "spams" the changesets with useless (for us) information, which makes it hard to compare changes. A solution could be to have a repository-wide setting whether to ignore or to use file system permissions.

Hiho! We recently upgraded our server (and simultaneously all clients) from 9.0.16.4392 to 10.0.16.5882, and since then, many of our users report the problem that files in the Pending Changes that are CLEARLY text file are listed as binary, and thus cannot be reviewed. We already tried both the local and global filetypes.conf, but as it seem this does not help (=is ignored) for Private and/or Added files. Granted, these files cannot be diffed, as they are not (yet) in version control - but the User still wants to have these files DISPLAYED in the client, for review before committing them. Also, in the past the detection whether a file was txt or binary was working very reliably (even without filetypes.conf, which overrides auto-detection and forces either text or binary for ALL files with that file extension), so something seems to have changed between these two versions, which is now affecting the detection. As additional info, the files we are having problems with are usually Unity YAML files, such as *.asset, *.unity, *.prefab, and so on. => could you please either fix the regression with the txt/binary auto-detection, or if that is not possible, at least have the filetypes.conf also apply to Private/Added files (as opposed to only files already in version control)? Thank you very much! Cheers, Wolfram

Yes, exactly.

Correct. But it also seems like it does not communicate wth the server about the actual/current license state of the server: As I said, in 26972 it claimed everything was OK, when in fact the server had already revoked the current license (from the token - no plasticd.lic file present at that point!). So it is not possible to discern the current state of the server using the WebAdmin - which makes it rather useless for this task it is designed to do. :-/