Unsure what to expect from hidden_changes.conf and cloaked

[Francois Bertrand]

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!

[Francois Bertrand]

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

[calbzam]

Hi Francois,
 

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). I believe this is a very common use case.

In that case, you need to use "hidden_changes.conf".
 

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"?

Do you also have the files as checked-out? If the files are only locally changed (not checked-out), it shouldn't appear in the "Pending Changes" view. 
Are you using Windows Plastic GUI?
 

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 understand. It fits pretty good with the purpose of "hidden_changes.conf". Please also open the "Options" panel in the "Pending changes" view and be sure you don't have enabled "Show hidden files".
 

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 AND doesn't show up in "pending changes" or any such operations, BUT that the user can manually "force update" if wanted?

The "hidden_changes.conf" will prevent you to create new revisions of this file (bu hiding your changes) but it won't prevent to download the new revisions if somebody creates a new revision of this file in the branch.

Regards,
Carlos.

[Francois Bertrand]

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

[calbzam]

Yes, we could clarify the error message for this specific case (hidden changes). If I properly understand you need to keep these files under source control? Because another option would be to keep them as private in your workspace.

Regards,

Carlos.

[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