Francois Bertrand

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.

Hi! I didn't get it recently, but am still getting this on Mac: Thank you!

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!

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!

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.

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

Hi! Pretty much every day, we get this error and need to restart Plastic, both on Windows and Mac! Thank you for any assistance.

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!

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