Francois Bertrand

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

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

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

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

Yes it was pretty much the same thing on our end; we assumed it was in until we tried it. That would really be useful! Thank you!

Hello Carlos, Thank you for listening to your customers' feedback! This is great and hopefully makes Plastic better. Cheers, Francois

I just wanted to bump this. This is making branch renaming a hazard; we don't rename branches that often, but when we do we never know if we might break someone's workspace completely. Are there any fixes planned? Again, thank you; we just want to make Plastic as robust as it can be! Francois

I've read that there seems to be a branch Explorer configuration file that MIGHT contain someone's relayout, but it seems it is not stored in the same spot as the other configuration files. 1. Is that the case, and if so how can we share a layout between all the team? 2. I could not find the "enter relayout mode" button on Mac, is that available? Thanks again!

These changes but good! But I do have to say as an end user the GUI is not the painful part of Plastic, but rather unexplained/strange conditions. Any effort to address error states/messages better would be an even bigger win, in my opinion. Just these 2 we brought up here for example: Renaming a branch causes other workspaces referencing it to "break" without explanation (just error messages) "Hidden changes" causing a warning that looks unrelated, every single time you switch workspaces (even if having changed files locally is the intended usage pattern for hidden changes!) Also not being able to use shelving for cloud users would be nice. Anyhow, we really like how you're being responsive again these are meant as constructive criticism. Thank you!

They indeed cannot coexist, but I CAN rename using "mv", so not sure what that means exactly. We were going off of previous answers about "macOS is case-sensitive", so hopefully this thread can help other people also. Thanks again!

Got it, thank you. I know it's probably not a trivial change, but as an end user that feels broken and causes confusion. Looks like basic use of the "rename branch" functionality can cause direct errors that are not explicitly explained. (we had people freak out when their workspace was all of a sudden broken!) Perhaps prohibiting renaming a branch if any other workspace is pointing to it would be an answer? Thanks again. I know I've been hammering you guys on the forums but we use this tool every day and hopefully it helps build a better product. Francois

Awesome!!! Thank you!

Hello Carlos, Just checking to see if you were able to fix the issue or had an ETA. Thank you!!! Francois

Hi! We have run into issues in the past renaming branches, where some clients "lost track" of a branch they were on when checking back in. I forget the exact issue but it was related to branch-tracking seemingly using names as the key. When is it not safe to rename a branch? (e.g. when someone else is working off of it? when there is a merge in progress or if there will be a merge in the future? etc.) We would like to rename branches on our project but we want to make sure no client gets errors. Thank you! Francois

Hi! I know that Windows is case-insensitive, but we are trying to change the case from a Mac client on a Cloud repository, and the Mac client keeps saying "a file with that name already exists". Should this be happening? Thank you! Francois