Francois Bertrand

Hello Carlos, Yes it would be really appreciated to get a custom "These changes are hidden, just so you don't forget" message instead of this error message! As I mentioned, yes it's important to keep these files under source control. They represent "known good/default" configurations or libraries, that each developer can/should customize for development. So the known good/default SHOULD be under source control (and updated periodically) but developers should have the freedom to modify them. Following our discussion, that seems just what hidden_changes was made for, which is great! (It just feels weird to have errors pop up when we use it correctly!) I hope that makes sense, and thank you for your continued support! Francois

Hello Carlos, Thank you for the answers. I'm glad that "hidden changes" is a great use case and we will be using it. I have to say that the confusion from a user standpoint is that most times we switch branches, we get a "warning: these files have been changed" message. I am attaching an example. We can safely ignore it since these are all in our hidden changes, but I think it would be very useful for users if you used different wording, such as: "The following files have been changed in the workspace but are marked in hidden_changes.conf, so they are probably safe to keep. If you wish to undo your local changes, you can try to update forced this item." or something along those lines. It is just unfortunate that something in hidden_changes seems to be a "problem" and a "warning" is triggered. Makes it look like it is not something that should be happening, whereas the hidden changes file IS for that exact purpose. Thank you, Francois

Hi! We recently found ourselves in a strange situation where we had to switch between changesets. We had to deal with some issues of "this file was changed", changing ignore lists between change sets, etc. but things seemed to be fine: we had returned to the latest changeset, and there were no pending changes. However, some files seemed to be out-of-state, even though there were no pending changes. We found that the culprits were files showing an older change set in the workspace Explorer. Eventually, hitting "Update Workspace" fixed the solution by updating the changeset of the offending files. We were curious; by switching changeset to the latest, shouldn't the system have also made sure all files in the workspace were at the "correct" change set number for that version? Why would we need to "Update Workspace" right after switching change set? After looking online, we are not the only ones with this type of question (out of date files in a seemingly "clean" set up without any changes), so even if we did something wrong it would be great to know the underlying cause and correct procedure. Thank you!!!

To summarize I guess I have 2 fundamental questions: 1. I've got files in hidden_changes that are showing up in my "Pending Changes" window, with their status as "Changed / Hidden changed". Wouldn't hidden_changes make them not show up in the pending changes? It seems to know that they are hidden, but still showing them. So what is the effect of "hidden changes"? 2. The use case I am just trying to cover is for configuration files that we want to have a "known good/default" version in source control, but that each user can modify locally, that are left alone otherwise (without any other interaction for merging/updating). Such files should be "manually updatable" when the user wants to revert their local version to a "known good/default". i.e. another way to put it I think is: Is there a way to have files checked in the repository, that are downloaded if the user does NOT have them locally, but are NOT downloaded if the user has a local version. BUT that the user can manually "force update" if wanted? Thank you!!! Francois

Hi! I'm not quite grasping what the use of hidden_changes.conf and cloaked are. I've read the documentation many times but some of the wording is ambiguous to me and some of the behavior I'm seeing is not quite intuitive. I'd like to be able to put things under source control, but also be able to change them locally without them showing up in my list of changes every time (e.g. a locally changed configuration file or recompiled library). For example, I've got files in hidden_changes that are showing up in my "Pending Changes" window, with their status as "Changed / Hidden changed". Wouldn't hidden_changes make them not show up in the pending changes? It seems to know that they are hidden, but still showing them. So what is the effect of "hidden changed"? "Cloaked" seems to make the changes not appear on the list, which is what I want. But I'm still curious about what hidden changes would be used for. Thank you!

Hello Carlos, So if I understand you correctly, hidden_changes doesn't do anything other than change what is displayed in the pending changes view, but the changes are still taken into account as if they were not hidden? Thank you, Francois

Hi! We have some configuration files we would like to add to the repository under a basic state, so they get downloaded by clients. However, we don't want local changes to be detected as changes (i.e. clients can have their own personal configurations). I know adding them to the "ignored list" would work, but it would be nice to still have that "default" state in source control. We added the files to the "hidden_changes" configuration file. Documentation says "The hidden changes are controlled items that can be changed but the user doesn't want them to appear by default on the Pending changes view.". This does work, as we do not see them in pending changes, however it seems that sometimes (I have not confirmed that this is happening every time) when switching workspace to a new changeset we get the error message: "Warning: This file has been changed in the workspace, out of Plastic SCM control, so data has been preserved. Item is not up-to-date." It's like it knows to ignore it for pending changes, but when switching changeset it DOES want to overwrite changes. I'm sure there is something easy I'm missing but would be great to know what. Note: in the workspace explorer the file IS listed as: "Controlled / changed / hidden changed" Thank you! Francois