Jump to content

Francois Bertrand

  • Content Count

  • Joined

  • Last visited

Everything posted by Francois Bertrand

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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!
  6. Hello Carlos, Thank you for listening to your customers' feedback! This is great and hopefully makes Plastic better. Cheers, Francois
  7. 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
  8. 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!
  9. 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!
  10. 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!
  11. 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
  12. Hello Carlos, Just checking to see if you were able to fix the issue or had an ETA. Thank you!!! Francois
  13. 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
  14. 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
  15. Hi! I just wanted to inform people that the command line parameters we got from the Beyond Compare website have a subtle flip which made our merging eyebrow-raising: "C:\Program Files (x86)\Beyond Compare 3\BCompare.exe" /title1="@sourcesymbolic" /title2="@basesymbolic" /title3="@destinationsymbolic" "@sourcefile" "@destinationfile" "@basefile" "@output" Notice how the titles are flipped from the order of the file parameters... Anyhow, this threw us for a loop and I thought of posting here in case it might help someone. UPDATE: After submitting feedback, the Beyond Compare website have fixed it. Leaving this post here, for those who may be using the old parameters.
  16. Hi! I didn't get it recently, but am still getting this on Mac: Thank you!
  17. Hi! We are running into this dialog box on the Mac, especially when returning from sleep. This keeps popping and requires a restart of Plastic. Thank you!
  18. Hello Carlos, thank you for the details. Unfortunately, we are having trouble doing a relatively simple task and I think it might benefit to discuss here. Our situation feels pretty typical and is as follows: We initially created a few repositories without touching access since we only had one team so we have "administrators" and "developers" We would like to only give access to some of the developers to one of the repositories, let's call it "Project X" So, we created a new group called "Project X Devs" and assigned the right people and ran into a few issues: User experience feedback: We added "Project X Devs" to our Project X repository, however we had to manually compare it to the default "Developers", and painstakingly go through each checkbox, click "override" and then set the right value. This felt very clumsy and unintuitive. Then, we ran into this issue: we cannot remove "Developers" from that repository because it is telling us "Cannot remove an inherited entry". So the repository seems to be stuck with "Developers" (?) Thank you again for any assistance!
  19. Hi! I created a new group to which I want to give access to a repository, instead of the default "Developers". I can successfully add the group in the GUI, but by default it has access to everything except "advancedquery" (which is neither allowed or denied). When I try to change any other values (I am trying to match the old "Developers" permissions as I guess this is what I want to be doing?), I get a warning: "Permissions can be overridden to bypass inheritance. Mark as overridden then set the new value" This doesn't seem to make any sense as: the group I created (in the cloud dashboard) is not "inheriting" from anything I'm not sure why these permissions are the default (everything except "advancedquery" doesn't seem to be a set of permissions from any existing group or user) I'm not sure what happens if a permission is NEITHER allowed or disallowed Thank you for any assistance! All I am trying to do is have a bunch of "Developer"-like access but only to certain repositories.
  20. Thank you; having that flexibility to go straight to Cloud instead of push/pull is something we appreciate as customers. Shelving seems to be the only major feature missing, it would be great to get that as it is very handy. Thanks again, Francois
  21. Hi! Pretty much every day, we get this error and need to restart Plastic, both on Windows and Mac! Thank you for any assistance.
  22. Hi! We could really use shelving; we did not expect that functionality to be unavailable when using cloud. To clarify, we are using "centralized" workflow where everyone just points to the cloud. We did not see any advantage in having local repositories and adding a push/pull step, as the centralized workflow works well. Is there any plan to bring such functionality to Plastic Cloud? It would be much appreciated! Thank you!
  23. 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
  24. 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
  • Create New...