Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Wolfram

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 Windows. Cheers, Wolfram
  2. Sorry, forgot the additional Info: Plastic GUI, Windows,
  3. 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
  4. 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: .NET Core Client versions: 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).
  5. 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, 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).
  6. 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.
  7. Any update on this? The new behaviour makes it very easy to accidentally commit private files that are not supposed to be committed.
  8. 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".
  9. 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.
  10. 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.
  11. 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
  12. 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!
  13. 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).
  14. Hiho. Using, 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.
  • Create New...