Wolfram

Come to think of it, I seem to remember that for ticket 26972, the WebAdmin in fact claimed everything was in order while the server had in fact NO valid license. It's as if it displayed independent info (such as, the presence of the *.lic files or simliar) and then evaluated that incorrectly, as opposed to actually communicating with the running server and checking its ACTUAL license state (which at that point had revoked the subscription license).

Hi Carlos! Thanks for your reply! That's what I thought, and as I said, the server is running smoothly. This post was just to notify you that the state displayed in the WebAdmin is incorrect. In fact, when we had the original problem in July, the first thing I checked was the WebAdmin, and it claimed everything was in order and we had a valid license - this was really confusing! (I'm not entirely sure whether there was both an (old+inactive) plasticd.lic file and a current plasticd.token.lic file in /opt/plasticscm5/server when we had that problem). I now removed the expired+obsolete /opt/plasticscm5/server/plasticd.lic and restarted the server, and now the WebAdmin display matches the server info again, and the displayed expiration date has correctly been updated to 28-Aug-2021. You still might want to fix the WebAdmin display to reflect the actual server state, though - otherwise it is little helpful when trying to check for errors. Cheers, Wolfram

Hiho. The license state shown in the Web Admin Interface does not match the actual state of the server. In July, our server lost the license (despite being configured to auto-renew) due to connection problems on your side (see resolved ticket 26972). I did not mention this then, but the whole time the web interface claimed the license was still valid, even when the server said it was not. As a quick-fix back then, I downloaded the license file manually and installed it on the server. The auto-renewal license token was/is still active at the same time. On July 28th, the manual license file expired. However, the server is still working correctly, recognizing our license subscription, as it apparently uses the auto-renewal token instead, so there was/is no problem in the workflow. HOWEVER, now the web interface shows the reverse situation: it claims the license has expired (which is true for the manual license file, but not for the auto-renewal/subscription), but the server is working correctly. It seems the evaluation order of license file vs. token file is inconsistent between server and web interface. EDIT: I should probably mention that we're currently on a rather old server version, 9.0.16.4392 .NET Core on Debian, but we're planning to upgrade to the current version tomorrow.

Hiho. Apparently you are doing some form of syntax checking when displaying/diffing files. However, it is displaying incorrect errors for Python files (see screenshot). Since Python 3.6, there is a construct called "f-string" or "Literal String Interpolation", and the highlighted line of code is perfectly valid syntax. However, the diff window claims there is something wrong. Using 9.0.16.4392 Windows. Cheers, Wolfram

Sorry, forgot the additional Info: Plastic GUI, Windows, 9.0.16.4392

Hiho. Minor: In the diff window, for image comparison it is possible to zoom in (which is good), but when zoomed in, using the scroll wheel in the main area does not scroll the zoomed image up and down, as one would expect. More relevant: In the diff window, for the "Swipe" mode during image comparison, the swipe slider vanishes (=scrolls off screen) if you are zoomed in and are looking at the lower part of the image using the side scrollbar. Cheers, Wolfram

Update: We recently moved our server to a different url, and since we used non-relative xlinks in our repos, using serveralias.conf is now mandatory for us. When entering the new server url in the preferences, in our team of 17 people, about 5-8 experienced this problem, the globalconfig of the new server was NOT downloaded. Restarting the client se4veral times, or even rebooting, did not help. We did find a reliable workaround that fixed the problem, though: Create a new workspace for an existing repository, and update that workspace so the repo's content is downloaded. After doing this, the globalconfig folder for the new server immediately appeared in the .plastic4 folder. Server version: 9.0.16.4392 .NET Core Client versions: 9.0.16.4392 or newer Connection to new server WITHOUT ssl (the old server used ssl, but we were for some reason unable to configure the ssl connection with the new server).

Any suggestions or confirmation? Thanks!

If a file got deleted and one wants to see the file's history from a previous changeset, many changesets are missing from the diagram (example one: lots of deletes (on different branches) in the list history, but the last entry in the 2D view is changeset 1000. It gets worse: in another case, a file was modified on a subbranch of /main/nard1 (1819 and 1834) (=> note: the merge-back of these changes into /main/nard1 is NOT listed, which might be considered as another bug?), then moved, and finally deleted in 2190 (on a DIFFERENT subbranch of /main/nard1), which was then merged back to /main/nard1 in 2192. However, when looking at the 2D diagram - it is completely empty! NONE of the deletions are shown, and what's worse: not even the changes or moves in 1819 etc.! If the Toggle "Only relevant" is disabled, tons of "U" changesets are shown - but again, none of the deletes, and none of the changes and moves. I also attached my Branch Explorer options, which do not constrain the view in any relevant way. If I explicitly right-click on 1819 in the list history and "View history as 2D revision tree", this particular changeset suddenly appears (screenshot "example2d") - but the change in 1834, as well as others, are still not shown. Using 9.0.16.4078, but this bug has been around a long time. Also note: the list-history-view shows useless informations for deletions and moves in the "Branch" column (i.e., "file was deleted" and "file was moved"), instead of the branch name. This makes the attached lists 1a and 2a essentially unreadable, as there are tons of deletes, but you have no information on which branch they happened, and you cannot get any further with the right-click menu: it has only two entries for these cases, ""History: list of revision" (which just REOPENS the same, current list in another tab), and "View history as 2D revision tree (which is greyed out).

Looking further into this, the description of the "Always select private files" is confusing: "selecting" suggests the square toggle to the left of the file is automatically applied to private files, for example when Plastic auto-selects candidates, or when you click "Check/Clear all", or select a subtree. But these files always get "selected", no matter whether this flag is set or not. The difference seems to be that if that flag is on, selected private files will be automatically ADDED/committed when committing, even when their status is still "Private". When it is off, they are ignored (=the old behaviour). BUT - and here comes the bug: this onyl works when these files are selected with "Check/clear all", or by selecting a parent directory. When you explicitly (or accidentally) select a single (or multiple) Private files, they will ALWAYS be committed, despite "Always select private files" being off.

Any update on this? The new behaviour makes it very easy to accidentally commit private files that are not supposed to be committed.

If you do not have pending changes that means your current workspace is a valid changeset. Therefore you can simply right-click on the changeset you want to diff with, "Diff with other changeset...", and then select the changeset you are currently on (which will be listed in bold). The second approach is to select the changeset you want to diff, then click the "home" button branch explorer to move the view to your current changeset, then ctrl-click that changeset (this will select BOTH changesets), and right-click "Diff selected changesets".

OK, the problem was not the Branch Explorer - here the adjusted date seems to work, and also seems to be stored. But for several other windows, I continuously have to reset this, either once per workspace, or sometime every single time. Some example of which windows are affected: Changesets: Here there isn't even a date field. So to show ALL changesets (which is necessary if you want to search for a keyword), you need to click "Advanced", then manually select the "where date > '...'" part and delete, then Return/Execute. But even then, this is per workspace(?), and even "Set as default query" does not work across repositories/workspaces. "View history as a 2D revision tree": for every file, a different date seems to be shown in the "A given date" field => OK, checking this again in detail it seems, this date is automatically chosen to be the date that particular file was FIRST added to the repository. Can you confirm this? If that is the case, the current behaviour is fine, I guess (as there is never any information hidden/missing), it's just confusing that the date changes, unless you KNOW this is actually the date when this file was introduced (which can be useful information) There may be other windows/subtabs that are effected, I'm not sure. For example, the branch explorer "Show selected...in a new diagram" seems to be fine, as it seems to use the date setting from the main branch explorer.

Well, it would allow the user to create his own prioritization. For example, the problem I decsribed could have been immediately resolved by this (by stating, "do NOT ignore folders and their contents named "Samples~"", but then followed by "still, ignore everything in /Library, and everything (else) ending in ~"). But it might cause problems in other situations (and of course it would be a hassle for everyone modifying their ignore.conf to comply to this new behaviour), and even without it it was possible to resolve my problem. Hm, this does not seem to be the case. With the mentioned ruleset we now use, ~-Files in Samples~ are still ignored, and I am able to both explicitly ignore other files in Samples~, as well as un-ignore specific ~-Files in it.

Ah, I wasn't aware that the exclusion-! can also be used for regex lines, nice! Also it's great that you appear to be using a "complete" RegEx parser, instead of just mimicking the most common expressions. This way, I was able to use (?!Library/).* instead of [^Ll].* , using "negative lookahead", to explicitly only exclude "Library", as opposed to excluding any folder that starts with an "L". A question: The order of the rules/lines does not appear to be relevant in any way, is that correct? Also, if I use *~ instead of /**~, it seems I no longer need the "include the content of Samples~" rules. In my test repo, where I created various "~"-files, this seems to work now as intended. Or am I missing something? So the complete ruleset to handle my original problem is now: !^/(?!Library/|Assets/).*/Samples~$ !^/(?!Library/|Assets/).*/Documentation~$ /Library *~ *~.meta (this also continues to exclude Samples~ if it appears in the /Assets subtree, as well as in the root folder, which is actually another requirement I needed) True, but as Unity will convert their whole package system to their UPM format (including the Asset Store handling, from what I hear), this will be a situation all package developers will face in the near future. Thanks again for your help! 😎 Cheers, Wolfram

Hiho. Our global ignore.conf for Unity projects looks something like this (I removed several other entries not relevant to this post): !ignore.conf /Library /ProjectSettings/ProjectVersion.txt *~ /Library contains workspace-/Unity-project-local files we don't want to be in version control. Same for /ProjectSettings/ProjectVersion.txt : We do need /ProjectSettings/*, but that particular file contains information about the local Unity project workspace. Many editors store backup files by appending a "~", so we ignore all of these (these files are also ignored by the Unity editor). I'm actually not sure if we do need the !ignore.conf (or maybe better, !/ignore.conf), but it's there since we initially setup our server, and it's not causing problems. Now, Unity is switching to a powerful package system called UPM (a variant of the npm Node package manager), so that the Package Manager in the Unity editor can handle installation and upgrade of software components and assets. Unity stores installed packages in /Library/PackageCache, and the configuration in /Packages/manifest.json. Our ignore.conf is still good for that, because we only want the configuration, but not the actual package content (Unity takes care of this itself). The problems come when developing your own packages. We store them in say /MyPackages, and we can tell the Package Manager to look for them there, as if they were regularly installed. However, the packages can (and will) contain two special folders, "Documentation~" and "Samples~", with a "~" at the end, and these folders (and their content) need to be in version control, along with the rest of the package. The "~" cannot be omitted, as this would make the folders visible to Unity, which will cause errors due to duplicate files/IDs. So my first approach was, "do not ignore these particular folders": !ignore.conf !Documentation~ !Samples~ /Library /ProjectSettings/ProjectVersion.txt *~ However, the result of this is that on the one hand, the other ignore.conf rules are NO LONGER APPLIED to any file having "Samples~" in its name. In particular, suddenly files like "/MyPackages/packagename/Samples~/old.tx~" show up in the pending changes, which I still want to exclude. On the other hand, for installed packages these folders (and their content) suddenly show up as /Library/PackageCache/packagename/Documentation~/readme.md and so on, but I STILL want these to be excluded. So how would I have to setup our ignore.conf to: ignore ALL files and directories ending in "~", EXCEPT directories named "Samples~" and "Documentation~" anywhere in the tree (or a possible simplification: ONLY in the /MyPackages/* tree) but at the same time STILL ignore EVERYTHING in /Library, even if there are directories named "Samples~" and "Documentation~"? (I did check the evaluation order in https://plasticscm.com/book/index.html?utm_source=plasticscm-blog&utm_medium=blog-post&utm_content=configuringignoreditemsinyourworkspace#_pattern_files but cannot find a working solution). Thanks!

Hi psantosl! No, that was not it. I understand what this new toggle does, but in my configuration/installation it is disabled, and it seems it is also disabled by default (=when deleting my local config and re-starting Plastic, it is still off). However, what changed as opposed to previous versions is the BEHAVIOUR of what happens if a Private file has its checkbox marked when committing. Previously, these files were simply NOT committed (as they were marked PRIVATE, meaning they are NOT registered as "Added" to revision control). NOW any file that has its checkbox marked WILL be committed, no matter whether its state is "Added" or "Private", and no matter whether the "Private" state was applied automatically (=the default for all newly created files), or whether the file was EXPLICITLY set to "Private" (e.g., it is a local and/or temporary file you don't want to commit yet/at all). While I understand the reason for changing this behaviour may have been to prevent mistakes of people forgetting to add files to revision control before committing, with the new behaviour it can instead happen that you commit files you did NOT want to commit, and IMHO this mistake is MUCH more dangerous, as it can now happen that you inadvertently commit security-critical files, or local project files that must not be visible on the server, or Gigabytes of data files you did not want on the server, and so on. With that new "Private files are always Added" paradigm, you also essentially removed/broke the feature of having private, local files (that the Workspace owner does NOT want to list in a ignore.conf, for whatever reason), as there is now no longer a difference between the states "Private" and "Added" (especially if the "Always select private files" option is on).

Hiho. Using 8.0.16.3651, and to my horror I discovered that a Checkin via the Pending Changes window suddenly commits ALL items that have their checkbox selected - even Private ones, i.e. items that were explicitly NOT added to revision control! In the past, these items were simply ignored, as you need to manually "Apply local changes" (or "Checkout", as it's called now). I was pretty sure I read through all the Release Notes of all public versions (even the "hidden" ones that are no longer accessible via the Download page), and I don't remember seeing any mention of this. This is a vital workflow change that can easily break projects if people do not know about it! 😞 So is this a bug, or is an intended, new behaviour? At the very least there should be a warning dialog, or a different Checkin option that will also affect Private files. Note that the current behaviour also creates an inconsistency between the "Checkin" and "Undo changes" buttons: Previously, both buttons ignores "Private" items. Now Checkin treats these items as "Added" (despite them being "Private"), while the Undo still ignores them.

EDIT: sorry, apparently I'm still asleep... x-P Ignore this post, I can't delete it. I just realized you are talking about attributes, not labels. But maybe there is a similar problem (i.e., that not all attributes are checked?) This sound like the following bug, for which a fix will be released soon:

In the end it won't make a difference, but in your case you should consider making only ONE attribute (such as "Build Version"), and then use the attribute value to set it to Windows or Mac (and then use "attrvalue" instead of "attribute" to query these). The idea of attributes+values could be compared to an enum, while just using the attribute itself (and only having a single possible value that is always set, such as "true") is more similar to a bool/flag. It would be a useful feature to also have special "flag attributes" for these, which are just set, without requiring a value. But the overhead of also setting the value to "true" is probably not that big (especially since you can click on the right of the "Value" field, there is a hidden drop down menu which will show you all values this attribute currently has).

Yay, that was quick! Thanks! ☺️

Thanks for the reply! Yeah, I assumed as much. However, it currently creates an inconsistency: If the user starts relying on the coloring, he will miss the middle changeset in the example above, as it contains a label with "Release", but that changeset's labels are not colored. Splitting up the arcs and coloring them individually might be a lot of effort on your side, with possible side-effects. A quick solution might be, to have the label rules match all labels with an "OR" concatenation, instead of just checking the first label. So in my example above, all arcs would be colored, if ANY of the attached labels match the rule. This would correctly color all three changesets according to the 'name like "%Release%"' rule. Prioritization if there are several matching rules would simply be determined by rule order (as it's already done with branch colors and so on). This solution would even work for Linux+Mac, which don't visualize multiple labels on the same changeset. But currently, the label (or even branch) coloring rules for these platforms aren't implemented yet, anyway. Also, you have the "OR" rule already working for the filter/search field: if I search for "release" (even case-insensitive 😉 ), all THREE changesets will be highlighted, no matter the order in which these labels were originally created. If I search for "Unity", only the middle changeset will be highlighted.

Nice, thanks for the link!

That link may still work, but as far as I can see it is no longer referenced anywhere. So unless you know the specific version you want to see the release notes for, you cannot access it. This is for example why I missed the release notes about the statistics window being removed, in the thread linked above.