lrg_steven

It seems that shelving can sometimes cause this issue. The steps to fix are: Go to the Workspace Explorer Find the file in question Right-click and select History to see the file history screen There will be a list of revisions on the left side and if you're seeing this error, the most recent one is probably not the bold one If you're sure that you want to overwrite the file first backup your changes because the next step will lose them After changes have been backed up somewhere else, right click on the newest entry and select "Revert file to this version" The bold text may not change, but if you re-apply your changes to the file, you can check it in and the new checkin will be bold in the history

Are there any instructions on what to do when receiving this error on a file that has only ever been edited in the main branch and it is now blocking checkins to the main branch?

I deleted Plastic entirely, deleted Plastic4 from AppData and deleted all the leftover files in Program Files, restarted my computer, then I reinstalled plastic, pulled a new copy of the repo into a new workspace, manually made my changes to my project again again using WinMerge (from a backup copy of the workspace files), and still I can not push.

It seems like it might be random what files it is accepting and rejecting. Not all of them are binary files. It will throw the error on some tiny .cs files too.

Same behaviour "Invalid credentials, username or password are not valid." popup, but if I commit one file at a time, no errors. I installed the latest version, have signed out and in several times, deleted my client.conf file, and still the error happens when I try to commit new files but not when I'm just committing changes, or just adding one or two files at a time.

I'm trying to move a 30GB repo from git to PlasticSCM. I've followed the instructions here: https://blog.plasticscm.com/2011/10/connecting-plastic-scm-to-github.html When I execute cm fast-import repo@company@cloud repo.fe --export-marks=marks.cm Everything seems to be running normally. The operation takes a long time and regularly updates its process. It eventually finishes and says what it has detected in the repo but then nothing appears in Plastic.

I'm glad that I saw this post. PowerShell messes up git exports so badly, it should probably be noted in the docs. The only time I've ever done a git export was for this. I thought it was weird that the PowerShell export took hours and produced a ~50GB file for an ~30GB repo. Doing everything on the normal command prompt produced a ~30GB file in less than a minute and I don't get that weird "]uldn't process command [??b l o b" error when importing.

In the newest version of the Plastic SCM plugin for Unity, it seems that we can no longer prevent overwrite on failed checkouts. Is there a workaround for this? Will this functionality return? Did we just miss something? We are working with plastic cloud edition. Thanks for your help!

Thanks, Patrice. I'll need to make some time to give that a try.

Thanks for the info! Any idea what could cause a file to become locked without having it in Pending?

Is there an easy way to get the GUID from the Plastic SCM GUI?

Since cm unlock doesn't have any output, we didn't realize that the command wanted a GUID

We are having an issue on Cloud where a file is locked, the user who locked the file has nothing in their pending changes, the user can not "Undo Checkout", the repository owner on Plastic SCM can not "Undo Checkout", and "cm unlock" on the repository owner's machine does not unlock the file.

We're working with Cloud so this type of trigger still seems useful. Though, for 2, we'd want to ensure that the file in our current branch was the most up-to-date across all branches. I looked at the trigger documentation but I did not see a good example of how to do something like this.

We've been having a problem with locked assets being overwritten because the project settings to prevent it are stored in EditorUserSettings (a file that Unity says should be ignored in version control) instead of inside the VersionControlSettings file that is stored in version control. Unity 2020.3.0

Did this solution work? The cm integration for Jenkins fails out of the box still on macOS. Since we're just running it as master, the fastest fix was to specify the executable in Manage Jenkins > Configure System > Plastic SCM > Command Line Client Executable: /usr/local/bin/cm You can access it using sh if you add it to the path in your pipeline script environment { PATH="/usr/local/bin:$PATH" } Note that updating the path in the script does not fix the original plugin issue.

I believe I was using it incorrectly. I read "If the checkout operation succeeds, these environment variables will be populated with the appropriate values for the build" and assumed it meant that existing environment variables would be populated. I was not fetching them from the dictionary. Thanks for the help!

The environment variables listed on the Jenkins plugin page return null for me in pipelines (https://plugins.jenkins.io/plasticscm-plugin/#documentation). They are null in both the stage where I do my cm call and other stages. I'm new to Jenkins Pipelines so I'm not sure if there is something simple that I'm missing. stage('Update Repository') { steps { cm( branch: '/main', repository: "${PLASTICSCM_TARGET_REPOSITORY}", server: 'mycompany@cloud', cleanup: 'STANDARD', directory: 'win64' ) echo "${env.PLASTICSCM_CHANGESET_GUID}" echo "${env.PLASTICSCM_AUTHOR}" } } stage('Check variables') { steps { script { echo "${env.PLASTICSCM_CHANGESET_GUID}" echo "${env.PLASTICSCM_AUTHOR}" } } }

Are xlinks on the roadmap for cloud? It's not clear in the documentation what is supported where.

Correct. We don't understand the unusual behaviour either. The packages are all installed in the same project in the same repo and the three machines have pulled from that repo.

This happens in 2020 as well. The unusual thing is that we put the same changeset on three different computers all running 2020.1.12 and the Antlr3.Runtime error only happens on one of them.

That's good to hear. I know good documentation takes time to write, so even a note in the interim telling users that the documentation is forthcoming would be useful.

This really needs to be added to the Jira integration documentation. I wasted a lot of time trying to figure out why the steps were not working.