Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Wolfram

  1. 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.
  2. 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
  3. 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!
  4. 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).
  5. 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.
  6. 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:
  7. 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).
  8. 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.
  9. 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.
  10. That sounds interesting, thanks πŸ™‚ It's not an absolutely vital feature, of course, but it would help for these cases. Although an overview page with links to all release notes would do the same trick, and would be less effort on your side. I'm still curious, though - why DO you delete some of the previously released versions, although you already have a page dedicated to previous releases?
  11. Hiho. Thanks for the new feature that allows us to color labels individually! πŸ™‚ However, in certain situations it doesn't seem to work correctly yet: We added a rule 'name like "%Release%"' to our clients: This does work if there is only ONE label on a changeset. However, with more than one label, the rule is evaluated only for the FIRST label, and then applied to ALL labels on that changeset. In this example: We added a label containing the word "Release" to the first changeset (which is colored correctly). We added a SECOND label containing "Release" to the second changeset (which already had one label). Note that all labels have the default color, which is not correct. We added a label containing "Release" to the third changeset, and THEN added another label to it, without the word "Release". Note that all labels have the filter rule color, which is not correct. (note that both in the graphics, as well as in the context menu, the label orders are reversed, so for the middle changeset, the label shown as "this is a Rele..." is actually the SECOND (=newer) label, not the first) (using Windows) Side question: is it possible to specify a case-insensitive filter/coloring rule, or do we need to manually combine them (for example, by using 'name like "%Release%" or name like "%release%"')?
  12. Well, it's not that we absolutely must RELY on a specific version, so we're fine using the next version in order. But we like to stay consistent within our team, instead of having 15 different plastic versions floating around, each behaving or looking slightly different. So it's just very confusing that you keep a list of "previous versions" - but that list only contains SOME of the previous (yet public) versions, while others are missing. And as I just learned from another thread, this way even the Release Notes of these deleted versions are no longer easily accessible (unless I missed something?), and therefore information about potentially important changes can no longer be found. πŸ˜•
  13. OK, good to know. I didn't find something about this in the release notes, though, (but maybe I missed it, or forgot about it, as it's an old change), and the page you linked to still mentions that the legend diagram can be displayed using the "Information and help" button πŸ˜‰
  14. Well, this version is not listed in the "previous releases", and therefore these release notes are not referenced anywhere (as far as I know) 😞 As such, this inconsistency is another direct result of what I described here: Where/how can I find other release notes that are no longer listed because of deleted versions? That's a pity, but probably can't be helped. Well, I wouldn't say we used it REGULARLY, but several in our team liked the quick overview, such as who actually worked on the project, which are the most volatile files, and so on. Can this info still be extracted with some magic CLI commands? The reason why there was no feedback about this from our team is, that we like to uniformly use the same version for all team members, until sombody (i.e., me ^^ ) finds the time to check the most current version, read all release notes, and test the new version with our environment. And until today, we were all working with x-P
  15. Hiho. I wanted to try the new "EnableIncomingChanges" feature (build 3636 Windows), but all I get is a "DiffWithChanges" error dialog, and I am unable to proceeed from there. What I did: positioned myself on /main, but not on the newest changeset added a few Private files to plastic by using the "Checkout" command closed the client added this line to the client.conf: <EnableIncomingChanges>yes</EnableIncomingChanges> re-opened the client in the Pending Changes, clicked "View new changes" in the Incoming Changes window, clicked "Update workspace"
  16. Hiho. For quite some time now (a year?), it seems the branch explorer legend help window can no longer be shown (Windows). In 2017, it was a separate button. Then it was hidden under the help button (you had to click a link in the help text that appeared). Then I seem to remember there was a time when even that link in the help text was gone. And now with the owl there are a lot of link that can be clicken, but they only redirect you to other owls, or to the webpage. Am I missing something?
  17. Hiho. I just upgraded from to (Windows), and the Change Statistics window is gone. In the left pane, the main entry "Review & Stats" is no longer there, and while "Code reviews" apparently moved to "Other Actions", I can no longer see the statistics view anywhere. The release notes also don't mention anything of this change.
  18. Interesting. I tried this now, and it seems to work. But I am also certain that in the past I had to modify this date quite often, even on the same machine, as it kept resetting itself to some seemingly arbitrary value. Maybe that was a bug that has been fixed by now? I'll keep an eye out for it.
  19. I noticed this in the release notes: I am the maintainer of our repositories, which means I need to work with the history a lot, and as such always found the date filtering kinda annoying and confusing since it's introduction...I have NO use for it whatsoever, I don't care about a few milliseconds delay, or a microscopic spike in the server load - but I WANT to see the whole history. Always. So a two-fold question: Is there a way to default the date filtering to "forever", or to something ancient, like 2010? For ALL repos and ALL workspaces? And ALL windows (branch explorer, changeset list, ...)? Currently I seem to (repeatedly?) have to reset this to 2010 for every single workspace (of which I currently have 70). Could you please add the field "Forever" to the new "Since:" dropdown, and make it configurable, so that this does NOT have to be set manually for every single workspace and window, on every single client? Thank you very much! πŸ™‚ Cheers, Wolfram
  20. Hiho. Why do you guys keep deleting (certain) old release versions from https://www.plasticscm.com/download/previous ? In our team we try to keep all working with the same Plastic version, just to be safe, and to ensure the same look and behaviour across machines. However, every time we point to a new download version in our guidelines, this version gets deleted after a while. A few examples: ... This is...kind of a weird policy, and constantly leads to confusion in our team (i.e., people complaining to me, that the version they are supposed to download is no longer available). πŸ˜• Thanks! Wolfram
  21. Just to clarify: the value needs to be given in bytes.
  22. Well, it HAS the effect of a certain animated paper clip from another company... πŸ˜‰ , at least for experienced users. Although I agree it's a great feature for new users, and sometimes (although rarely) does show you certain tricks you didn't know about yet, even when you have been using Plastic for years. For us, the biggest pain point is that you have to click through every single owl AGAIN every time you install the client on a new machine, or do a clean install. So an option to disable it would be helpful. But I wouldn't go that far to say it bothers us that much that we "hate" it.
  • Create New...