[Where did the Change Statistics window go?]

2 hours ago, S_Luis said:

About this:

I talked with the team and we are going to implement the following: a release notes portal in which you can select in a combobox an "origin" release, and another combobox to select the "destination" release. Then the page will give you all the release notes between those two versions (origin not included, I guess, as that's the one you have installed).

Would that be useful for you and your team?

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?

[new feature "coloring changesets and labels" not always working correctly]

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%"')?

[Old installers no longer available]

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. 😕

[Can no longer show the branch explorer legend]

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 😉

[Where did the Change Statistics window go?]

3 minutes ago, S_Luis said:

We removed it back in version 8.0.16.3274, as indicated in the release notes:

https://www.plasticscm.com/download/releasenotes/8.0.16.3274

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?

5 minutes ago, S_Luis said:

We decided to remove the "Change Statistics" because it was Windows only, it didn't provide much information, and almost no one was using it. This is the first feedback we hear about this, almost four full months after removing the feature.

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

["EnableIncomingChanges" results in error window]

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"

[Can no longer show the branch explorer legend]

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?

[Where did the Change Statistics window go?]

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.

 

[Possible to globally disable date filtering?]

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.

[Possible to globally disable date filtering?]

I noticed this in the 8.0.16.3594 release notes:

Quote

Windows - Plastic: We've added dynamic date filtering to the Branch Explorer. You can easily set the Branch Explorer to show changesets from the past week, month or year. 

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

[Old installers no longer available]

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

 

[Configure "too big for diff" threshold?]

Just to clarify: the value needs to be given in bytes.

[How disable help everywhere]

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.

[Plastic showing status Changed when files are identical]

On 7/10/2019 at 2:24 PM, prog112 said:

I understand that but for consistency issues having items which are not really edited in that list will certainly cause needless misunderstandings. Not only that,  but it litters the changes list so it's hard to gauge what you've truly changed. It is be something that now will have to be explained to every new team member.

We've gotten used to always do an "Undo unchanged" before any commit (=before going through the list to check the changes), it will remove any unmodified items from the list.
The only danger is to accidentally do an "Undo changes"...so always double-check you selected the correct drop-down entry 😉

[global ignore.conf ignored for one of our users]

4 hours ago, calbzam said:

The user who faces the issue could create a local "ignore.conf" in the workspace so you don' t need to commit the file to the repo.

Ah, good to know, I assumed that much. I was just taking the word of my colleague for it that he had to commit it.

I sent additional info to the email you gave, the ticket number is 18298.
Cheers!

[global ignore.conf ignored for one of our users]

Update: it seems the problem is an empty folder %LocalAppData%\plastic4\globalconfig (it just contains the correctly named but empty subfolder of our server connection).
Closing the client and completely deleting the "globalconfig" folder did not help, it just recreated the still empty server folder inside.

In his client logfile lines like this appear (but there are no confirmations whether it succeded or not):

2019-06-14 15:10:19,128 DESKTOP-N53JVKU\Eric DEBUG GlobalConfig - Try to get the server config from the file 'C:\Users\Eric\AppData\Local\plastic4\globalconfig\ssl_XXXXXXX_8088/allrepos\ignore.conf'

In mine that line is instead :

-06-14 13:08:02,150 NMY-PC7\wkresse DEBUG GlobalConfig - Try to get the server config from the file 'C:\Users\wkresse\AppData\Local\plastic4\globalconfig\ssl_XXXXXXXXX_8088\allrepos\filetypes.conf'

Notice in his log message (=broken client) the directory separator after the server path folder is "/" instead of "\" - maybe that is related to the problem?

There are no "ERROR" or "WARN" messages in either log file, except this:
 

[mine:]
2019-06-14 13:08:02,146 NMY-PC7\wkresse WARN  filters - PathValueMatcher: Error parsing line:       # Fichero de extensiones de Plastic SCM. Sintaxis: <expresión>:<tipo>.
2019-06-14 13:08:02,146 NMY-PC7\wkresse WARN  filters - PathValueMatcher: Error parsing line:       # El tipo puede ser 'txt' o 'bin'.
2019-06-14 13:08:02,147 NMY-PC7\wkresse WARN  filters - PathValueMatcher: Error parsing line:       # Ejemplos:
2019-06-14 13:08:02,147 NMY-PC7\wkresse WARN  filters - PathValueMatcher: Error parsing line:     
  
[his:]
2019-06-14 15:12:22,683 DESKTOP-N53JVKU\Eric WARN  filters - PathValueMatcher: Error parsing line:       # Plastic SCM extensions file. Syntax: <expression>:<type>.
2019-06-14 15:12:22,683 DESKTOP-N53JVKU\Eric WARN  filters - PathValueMatcher: Error parsing line:       # Valid expressions are: '.cpp', 'myfile.cpp' ... (Metacharacters are allowed: '*', '?')
2019-06-14 15:12:22,683 DESKTOP-N53JVKU\Eric WARN  filters - PathValueMatcher: Error parsing line:       # Examples:
2019-06-14 15:12:22,684 DESKTOP-N53JVKU\Eric WARN  filters - PathValueMatcher: Error parsing line:     

And for some reason, mine is in Spanish x-D
Not sure what this "extensions file" is - I don't think we configured one. But that warning might be unrelated.

[plastic client not using plastic-global-config/allrepos/serveralias.conf]

On 8/24/2017 at 3:01 PM, Johan Ung said:

[...] but could not get my globalconfig files to be updated. I simply removed the globalconfig folder and started the client back up, then it got the new config from my new repo.

We're having the same problem, the globalconfig folder contains only an empty directory for our server. Deleting it did not trigger a download, it just re-created the empty folder.
See 

 

[global ignore.conf ignored for one of our users]

Hiho.

Since a few weeks, the global, server-wide ignore.conf seems to be...ignored for one of our users. As a result, as we are using Unity, Pending Changes is constantly cluttered with thousands of files from /Library, and it takes 20-30 seconds accessing it each time, as the client seems to check each individual file.
For all our other users, the global ignore is working just fine.

The global file is /allrepos/ignore.conf in the repository plastic-global-config, and its first lines are:

!ignore.conf
/Library
/Temp
/ProjectSettings/ProjectVersion.txt
/obj

It seems independent of the project he is accessing, and re-installation or creating new workspaces does not help.

See attached screenshot. Note the state of all /Library files is "Private", instead of "Ignored".

The version he is using is 8.0.16.3257, but it also happens with older versions (such as 7.0.16.2637). According to him, this happens since he re-installed his whole PC from scratch (including Windows 10), so there was no previous %LocalAppData%\plastic4 .

 

A workaround we found was to explicitly add "Library" and "Temp" to the project-local /ignore.conf, and committing that. But it would be a bit inconvenient to unnecessarily edit the local ignore-files for all projects he is working on.
 

 

Any ideas? 😕

Thanks!

Wolfram

[Ignore changes in Filesystem Permissions?]

On 5/4/2017 at 9:38 PM, psantosl said:

You can stop using Macs... :-P

Tell that to our designers x-D

OK, thanks for the quick answer! Guess we'll just have to live with it then for now.

[Ignore changes in Filesystem Permissions?]

Hiho.

Most of our team is working on Windows, but we also have a few Mac users. Now every(?) time somebody commits something on a Mac, there will usually be several files that are unmodified, but are commited/need to be committed anyway, as they are marked as "Only filesystem permissions changed". In the diff window the info given is "Filesystem permissions changed from NOT_DEFINED to [...]".

As we really don't care about these (our main platform is Windows, and all our projects use Unity), we'd like to be able to prevent these changes from being committed/recognized, as they create a lot of clutter, making the Plastic client harder to use for our Designers and so on.

We didn't find a setting to influence this behaviour - is there another workaround (or CLI trick?) to have the Mac client and/or the whole database ignore all filesystem permissions?

Thanks a lot! :o)

[Renaming repository leaves dangling workspaces]

On 1/27/2014 at 3:49 PM, manu said:

There's an easy way now to recover the workspace.

 

1) Open the GUI.

2) Open the repositories view

3) Right click in the one having the new name

4) Select "View branch explorer"

5) Select any branch, right click ans switch to it.

 

Your workspace will be working now with the "new" repository.

This workaround fails if there are pending changes in your workspace, as you cannot switch your workspace to another branch if there are pending changes (yes, even if you set the "Behaviour when trying to switch/update..." to "Allow" in the Preferences (Windows-Client)). But you cannot discard your pending changes, as you will get the "repo not found" error. Even with the "cm update ." command.

So this creates a deadlock, and it appears the system breaks if you rename a repository, UNLESS *all* users in all their workspaces make sure they discard any pending changes BEFORE the rename is made...

Can you confirm that, or is there another method to recover or prevent this problem?