Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Kodo

    UnityYAMLMerge Error

    I tried UnityYAMLMerge from different versions of the unity. So far only for this prefab. On another computer, by another user (the same version of plastic and unity), the merge was successful. Maybe I need to install some kind of library for windows. I don't know what the difference is.
  3. Have you manually configured this tool as external merge tool, right? It seems the problem is this specific external merge tool is not able to handle this merge conflict. Are you facing this error for every merge conflict involving .prefab files or just this specific one? Regards, Carlos.
  4. Kodo

    UnityYAMLMerge Error

    Yes I have: "C:\Program Files\Unity\Hub\Editor\2018.4.26f1\Editor\Data\Tools\UnityYAMLMerge.exe" merge -p "@basefile" "@sourcefile" "@destinationfile" "@output"
  5. Hi, if you drive to Preferences --> Merge tools, do you have defined any custom merge tool for .prefab files? It seems a problem with the external perge tool (UnityYAMLMerge). Regards, Carlos.
  6. HI, I'm using Clion 2020.2.4 and have installed the Jetbrains plugin to enable PlasticSCM support. However, when performing an workspace update from CLion the following Java exception is thrown. (see below). Any idea what might be wrong? Regards, W. ------ java.lang.AssertionError at com.codicesoftware.intellij.application.PlasticUpdateEnvironment.updateDirectories(PlasticUpdateEnvironment.java:60) at com.intellij.openapi.vcs.update.AbstractCommonUpdateAction$Updater.performUpdate(AbstractCommonUpdateAction.java:384) at com.intellij.openapi.vcs.update.AbstractCommonUpdateAction$Updater.runImpl(AbstractCommonUpdateAction.java:353) at com.intellij.openapi.vcs.update.AbstractCommonUpdateAction$Updater.run(AbstractCommonUpdateAction.java:327) at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:935) at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressAsync$5(CoreProgressManager.java:442) at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:235) at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:170) at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:629) at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:581) at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60) at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:157) at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:235) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668) at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665) at java.base/java.lang.Thread.run(Thread.java:834)
  7. Good day, After reinstalling windows, when trying to merge, I get the following error: the plastic and unity version is the same.
  8. Sorry for not being clear enough. The plugin to use is this one: In the repo link, it's also refered as the "The TeamCity Lightweight Plugin". Please review the the following sections: https://github.com/PlasticSCM/teamcityplug Installation requirements - The TeamCity Lightweight Plugin TeamCity Configuration Please let us know if it helps. Regards, Carlos.
  9. Hi Carlos You're right, we only had the regular VCS support: Plastic SCM on our TeamCity server. I can't find any plugin for teamcity called "Mergebot plugin". The closest is https://github.com/PlasticSCM/teamcityplug, which talks about the mergebot. Is that the correct one? If not, can you throw a link to the right plugin?
  10. Hi, - I think the key is you have defined a stage "post" in the plug configuration. It's not mandatory and you can remove it from your configuration. 2020-10-16 13:10:54,176 INFO teamcityplug - stage: post - Also review that you have installed the "Mergebot plugin" but not the regular "Plastic SCM Teamcity plugin" that may be triggering a build every time a new changeset appears in the repo. Regards, Carlos.
  11. Hi Carlos, thanks for responding. I 100% agree that the logs say it shelved and tested the shelve, but TeamCity build logs said something else. Sorry i forgot to add a screenshot of the builds last friday. Build #31 is a test of the branch im about the merge into main, #32 is the build initiated by the bot, and #33 is me again building to test if main works after merge. This is the reason why we believe there might be something working differently than intended. Is there any settings, setups, or installations we've missed that could cause this issue?
  12. Last week
  13. Hi, I've been reviewiong your TRUNKBOT log: 2020-10-16 13:09:08,653 INFO trunkbot - Processing branch /main/HCHB_MacAutorun attribute change... 2020-10-16 13:09:08,654 INFO trunkbot - Getting task number of branch /main/HCHB_MacAutorun ... 2020-10-16 13:09:08,655 INFO trunkbot - Building the merge report of task HCHB_MacAutorun ... 2020-10-16 13:09:08,657 INFO trunkbot - Trying to shelve server-side-merge from /main/HCHB_MacAutorun to /main 2020-10-16 13:09:08,667 INFO trunkbot - Testing branch /main/HCHB_MacAutorun ... 2020-10-16 13:10:54,136 INFO trunkbot - Checking-in shelved merged 9 from /main/HCHB_MacAutorun to /main 2020-10-16 13:10:54,168 INFO trunkbot - Checkin: Created changeset 1863 in branch /main 2020-10-16 13:10:54,168 INFO trunkbot - Setting branch /main/HCHB_MacAutorun as 'integrated'... At "13:09:08" "testing branch /main/HCHB_MacAutorun", and if we review the plug log at that time, TeamCity is running the build folder the shelve: sh:9@HavenPlastic@http://192.168.59.56:8087 020-10-16 13:09:08,676 INFO teamcityplug - Launch plan was requested. Fields: 2020-10-16 13:09:08,676 INFO teamcityplug - PlanName: Haven_Test_Configurations_TestMerge 2020-10-16 13:09:08,676 INFO teamcityplug - ObjectSpec: sh:9@HavenPlastic@http://192.168.59.56:8087 2020-10-16 13:09:08,676 INFO teamcityplug - Comment: MergeBot - Building branch /main/HCHB_MacAutorun 2020-10-16 13:09:08,676 INFO teamcityplug - Properties: 2020-10-16 13:09:08,676 INFO teamcityplug - branch.head.changeset.author: mjensen 2020-10-16 13:09:08,676 INFO teamcityplug - branch.head.changeset.guid: ed01e110-4457-45db-9266-ebf2f8916974 2020-10-16 13:09:08,676 INFO teamcityplug - branch.head.changeset.number: 1862 2020-10-16 13:09:08,676 INFO teamcityplug - branch.name: /main/HCHB_MacAutorun 2020-10-16 13:09:08,676 INFO teamcityplug - build.name: 2020-10-16 13:09:08,676 INFO teamcityplug - build.number: 2020-10-16 13:09:08,676 INFO teamcityplug - label: 2020-10-16 13:09:08,676 INFO teamcityplug - release.notes: 2020-10-16 13:09:08,676 INFO teamcityplug - repspec: HavenPlastic@http://192.168.59.56:8087 2020-10-16 13:09:08,676 INFO teamcityplug - stage: pre 2020-10-16 13:09:08,676 INFO teamcityplug - task.number: HCHB_MacAutorun 2020-10-16 13:09:08,676 INFO teamcityplug - trunk.head.changeset.guid: 71ee7ee1-9bc2-4c8c-89cf-3cc367afab09 2020-10-16 13:09:08,676 INFO teamcityplug - trunk.head.changeset.number: 1860 At "13:10:54" the shelve that was already tested is finally checked in into main: "Checking-in shelved merged 9 from /main/HCHB_MacAutorun to /main". After that, the "/main/HCHB_MacAutorun" branch is set as integrated and a new build is run for the recently created changeset 1863. 2020-10-16 13:10:54,176 INFO teamcityplug - Launch plan was requested. Fields: 2020-10-16 13:10:54,176 INFO teamcityplug - PlanName: Haven_Test_Configurations_TestMergePost 2020-10-16 13:10:54,176 INFO teamcityplug - ObjectSpec: cs:1863@HavenPlastic@http://192.168.59.56:8087 2020-10-16 13:10:54,176 INFO teamcityplug - Comment: MergeBot - Running plan after merging branch /main/HCHB_MacAutorun 2020-10-16 13:10:54,176 INFO teamcityplug - Properties: 2020-10-16 13:10:54,176 INFO teamcityplug - branch.head.changeset.author: mjensen 2020-10-16 13:10:54,176 INFO teamcityplug - branch.head.changeset.guid: ed01e110-4457-45db-9266-ebf2f8916974 2020-10-16 13:10:54,176 INFO teamcityplug - branch.head.changeset.number: 1862 2020-10-16 13:10:54,176 INFO teamcityplug - branch.name: /main/HCHB_MacAutorun 2020-10-16 13:10:54,176 INFO teamcityplug - build.name: 2020-10-16 13:10:54,176 INFO teamcityplug - build.number: 2020-10-16 13:10:54,176 INFO teamcityplug - label: 2020-10-16 13:10:54,176 INFO teamcityplug - release.notes: 2020-10-16 13:10:54,176 INFO teamcityplug - repspec: HavenPlastic@http://192.168.59.56:8087 2020-10-16 13:10:54,176 INFO teamcityplug - stage: post 2020-10-16 13:10:54,176 INFO teamcityplug - task.number: HCHB_MacAutorun 2020-10-16 13:10:54,176 INFO teamcityplug - trunk.head.changeset.guid: b69336f0-ffb6-4e8e-a53e-722b08d036fa 2020-10-16 13:10:54,176 INFO teamcityplug - trunk.head.changeset.number: 1863 Regards, Carlos.
  14. I'm setting up mergebots to help with our CI/CD and I've run into a problem. We use the default trunkbot that comes with plastic server installation, but when we run it, it seems like it doesn't build from a shelve. Our plastic version is 9.0.16.4608 and TeamCity version 2019.2.1 Plastic mergebot logs show that the bot makes a shelve, but TeamCity runs the changeset already on main instead of that shelve. We did a test where we made changes to a branch to make it unable to build, but the mergebot still sucesfully merged it into main because main could build. After the merge main could no longer build. The logs in case you can see why it didn't work as expected. If there are any other logs that show why this happened, please let me know trunkbot.trunk.log.txtteamcityplug.TeamCityForMerges.log.txt Thanks in advance
  15. If you somehow find a reproducible scenario, we would like to get connected with him. You can temporary disable the FsWatcher with the following setting in your "client.conf" (although I still don't have any certany that this is the problem). <WatcherEnabled>no</WatcherEnabled> Regards, Carlos.
  16. Side note; one of my colleague reports that this happens to him multiple times per day. Once I have some more logs I will provide them to you via a support ticket.
  17. We are not able to easily reproduce it, sorry. The general repro steps are: 1. do a bunch of work in other applications 2. switch to Plastic SCM (which is already running) 3. switch tab within Plastic then, at step 3, sometimes there is a multi-second freeze. I have attached a redacted & cut-down version of the Plastic SCM logfile. Since I shut down the Plastic SCM client shortly after experiencing the freeze, I believe that the interesting part starts at 2020-10-13 22:15:20,498 . If you want the full, unredacted log, let me know and I will file a support ticket + include the log file. log_redacted.txt
  18. Hi, The editor we are using is developed by ActiPro.It seems they still don't have support for Python 3.6. Could you also share your problem in the following link? https://www.actiprosoftware.com/community/thread/24996/does-syntaxeditor-python-language-add-on-for Sorry for the inconveniences, Carlos.
  19. Hi Mikael, Do you have any user who is able to easily reproduce it? The log information you are attaching is everything for the same second (not 7 seconds). Could you attach the full log and let us know the stimated time when the freeze happened? Regards, Carlos.
  20. Why don't you run a query "cm find changeset..." instead of manually typing the changeset id inside the file content? The same happens if you need to query any changeset/branch metadata information: https://www.plasticscm.com/documentation/cmfind/plastic-scm-version-control-query-system-guide Not sure if you are aware of our mergebots feature. It allows to automate the branch intergation and it's based on the branch attribute value: https://www.plasticscm.com/mergebot-devops We are considring a new feature that allows to shelve/checkin individual lines or hunks as opposed to the entire file. Regards, Carlos.
  21. I honestly agree that there should be a better way to do it that doesn't generate all those conflicts... The workflow is that that we want to use the cs as version number when we build in with unity. It works well when we use TeamCity to build as it discards whatever changes is made when it builds, but if we want to build manually Unity reads from project settings what the version number is. Which is then saved and causes conflicts. There are workarounds which should be possible, but if Plastic had a way to simply ignore a given line it would be easier
  22. Hi, over the past month-or-two several of the developers on my team have noticed that, occasionally, the Plastic SCM GUI freezes for a couple of seconds when switching between tabs in the UI. The frequency which I observe this myself at is - say, 2-3 times over the past month, but I work only rarely within the editor. Others experience it more often. In the most recent case, the freeze occurred when I switched from a Branch Explorer view to a Pending Changes view by pressing Shift-Tab. The GUI froze for about 7 seconds. After that, I could switch back and forth freely without seeing any freezes. I run Plastic SCM with file system watching enabled. I have Plastic configured to determine file differences based on file hash, not just timestamp. I had sum total of 1 changed file on the machine. When I look within the Plastic SCM application log, I notice a sequence - about 7 seconds in length, which corresponds to the freeze I experienced - with entries like this: 2020-10-13 22:15:22,240 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change b for <REDACTED2> 2020-10-13 22:15:22,240 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 1 events/s 2020-10-13 22:15:22,312 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:<REDACTED3> type:Changed 2020-10-13 22:15:22,312 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 2 events/s 2020-10-13 22:15:22,312 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change a for <REDACTED4> 2020-10-13 22:15:22,685 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:'<REDACTED2>' type:Changed 2020-10-13 22:15:22,685 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 3 events/s 2020-10-13 22:15:22,685 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change a for <REDACTED2> 2020-10-13 22:15:22,689 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:<REDACTED5> type:Deleted 2020-10-13 22:15:22,690 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 4 events/s 2020-10-13 22:15:22,690 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:<REDACTED5> type:Renamed 2020-10-13 22:15:22,690 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 5 events/s 2020-10-13 22:15:22,691 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:<REDACTED6> type:Changed 2020-10-13 22:15:22,691 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher <REDACTED1>. Speed: 6 events/s 2020-10-13 22:15:22,690 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change c for <REDACTED7> 2020-10-13 22:15:22,691 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change d for <REDACTED7> 2020-10-13 22:15:22,692 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - Watcher <REDACTED1> - Processing change a for <REDACTED8> 2020-10-13 22:15:22,936 KALMSHOMEDESKTO\Kalms DEBUG WatcherFsNodeReader - FsWatcher. Event path:<REDACTED3> type:Changed No associated errors. It appears that the FsWatcher processed 33 changes in 7 seconds. That sounds low to me. 6 of those 33 changes are for a file that is ~45MB in size. All the other changes are for much smaller files (1MB or smaller), as far as I can tell. Is there any chance that the FsWatcher is related to the stalls we are experiencing?
  23. Hiho. Apparently you are doing some form of syntax checking when displaying/diffing files. However, it is displaying incorrect errors for Python files (see screenshot). Since Python 3.6, there is a construct called "f-string" or "Literal String Interpolation", and the highlighted line of code is perfectly valid syntax. However, the diff window claims there is something wrong. Using 9.0.16.4392 Windows. Cheers, Wolfram
  24. Hi, Why are are you editing the file content to match the cs you re working one? Why don't you use a different approach like using "attributes"? Could you describe the details of your workflow to understand why are you doing it this way? Do you need to keep under version control the file where you set the project version if then, you don't want to merge these changes? You could add this file to the hidden changes list (or keep it as private) so this way, you are not facing merge conflicts with it. Regards, Carlos.
  25. Hi, Could you attach the Plastic server debug log to review it? Also please attach the "server.conf" file. Regards, Carlos.
  26. Ok, thanks for the update. Regards, Carlos.
  1. Load more activity
×
×
  • Create New...