Jump to content

Wolfram

Members
  • Content Count

    70
  • 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. 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.
  2. 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.
  3. 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?
  4. 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 8.0.16.3636 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%"')?
  5. 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. 😕
  6. 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 😉
  7. 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 8.0.6.3221 x-P
  8. 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"
  9. 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?
  10. Hiho. I just upgraded from 8.0.16.3221 to 8.0.16.3636 (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.
  11. 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.
  12. I noticed this in the 8.0.16.3594 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
  13. 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: 8.0.16.3221 7.0.16.2637 7.0.16.2381 7.0.16.2183 ... 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
×
×
  • Create New...