Francois Bertrand 2 Report post Posted February 18, 2020 Hi! Thank you again for your continued support! I posted about this before but it's still very jarring for our team and is causing a lot of friction with some of our files. Basically, there are some configuration files & libraries etc. that need to be present, but customized/recompiled per-developer. We want to commit them to the repository as they DO need to be present in at least a "default" state, but then once downloaded, we want developers to not have to worry about committing them ever. This feels like a very reasonable and common use case, and one for which "hidden_changes.conf" is made for. However, when we switch branches/changelist (which is very often!), we get the following error-looking dialog for any files we are locally changing but that ARE in "hidden_changes.conf": Ideally, if a file is in "hidden_changes" it wouldn't cause such an error and not put up any dialog. (e.g. I know it's a different use case but files that are cloaked don't put up a dialog) If there are any concerns about communication at the very least it should be a more friendly dialog such as "the following files are marked as HIDDEN CHANGES and have been changed and will NOT be updated to the new change list". Thanks again, I hope that made sense (or if I am missing anything about the intended use case of hidden_changes?) and if a solution like this could be implemented. Francois Share this post Link to post Share on other sites
Francois Bertrand 2 Report post Posted February 24, 2020 Just bumping this topic to make sure; am I missing something obvious? It really feels like this is a common use case -> having a "default/baseline" version of a file (config/lib/etc) that gets downloaded if missing, but can be changed locally per-developer without any other warnings/errors. Thank you! Francois Share this post Link to post Share on other sites
calbzam 97 Report post Posted February 25, 2020 Hi, Could you include this request and details in our suer voice system? https://plasticscm.uservoice.com Thanks! Carlos. Share this post Link to post Share on other sites
Francois Bertrand 2 Report post Posted February 25, 2020 Hello Carlos, I did; however did my request make sense? Is this the typical use case for hidden_changes? Is there another way to do what we want to be doing? Thank you! Francois Share this post Link to post Share on other sites
calbzam 97 Report post Posted February 26, 2020 Hi, I agree that we could at least improve the error message for these files. Not sure if not including any kind of message when you switch your workspace with changed items is a good idea (supposing that these files are currently in "hidden_changes.conf" but maybe not in the future). Anyway, we will need to internally discuss the best approach. If you create the user voice, it will help us to track the request and potentially also get some feedback from other customers. Thanks! Carlos. Share this post Link to post Share on other sites
Francois Bertrand 2 Report post Posted February 26, 2020 Hello Carlos, Thank you for the follow-up; I already added the user voice item. If anything, at a minimum it feels like it would be relatively easy/simple to at least change the message to not be an error or "possible problems", when in reality the "hidden changes" feature is being used as intended. We use it a lot and every time we switch workspaces something feels "bad" about our set up, and it makes us used to ignoring messages that could be important. A more informational message like "For your information: the following files have changed but are marked as "hidden changes" so they will not be updated:" (and no mention of "a potential problem" either) would be great and let us know what is really going on. Compare this with the current message, for the same situation where we are simply using hidden changes correctly: "The report shows possible problems found during the update operation. Some items were not correctly updated. You may want to check the errors and retry the operation after solving the problems." Yikes!!!! Thanks again! Francois Share this post Link to post Share on other sites
