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. 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).
  2. 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.
  3. 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:
  4. 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).
  5. 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.
  6. 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.
  7. 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?
  8. 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%"')?
  9. 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. πŸ˜•
  10. 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 πŸ˜‰
  11. 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
  12. 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"
  • Create New...