Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Hi @Mikael Kalms, we need to release a new Plastic SCM version as well. The new Jenkins plugin is needing a new command that is not present in your installation. We'll try to do it today, keep tuned.
  3. Yesterday
  4. Hi pablo! Thank you for your detailed answers! > [pablo] Not sure if you knew this, but when you checkin, Gluon always warns you if the associated meta is not selected. Not sure if it is related, but thought it was good to mention. Unity plugin also does it, but we built this into Gluon too. Ah, that's good to know. So far we never really used Gluon, and we do have the plugin active, but do everything else directly in the client. >> - More importantly, it seems impossible to locally update or modify >> any assets that are listed in cloaked.conf - at all. I couldn't >> even get the "cm.exe upd --cloaked" workaround to do that. >> And here, even the "locally modified cloaked.conf" is not >> working - even when removing these files from cloaked.conf, >> they are still invisible for updates. > > [pablo] I don't follow this last part: I will double check if cm update --cloaked is broken, but it sounds weird. Hm, maybe I'm using it wrong. I tested it with files added to a cloaked directory, as well as explicitly adding a file from a 2nd workspace copy, and only then setting it to cloaked via that workspace, and committing this modified cloaked.conf Then I used the client to update the first workspace. As expected, the file was not downloaded, as it's cloaked. When I now issue a "cm update ." in the first workspace, I expect nothing to change. But when I say "cm update --cloaked .", I'd expect the new-but-cloaked file to be force-downloaded - which does not happen. Or does this only work with CHANGED files, not with new files? I do get a "Could not get revision information" error when I explicitly specify the file (which does not exist in workspace 1) by "cm update --cloaked Assets/Textures/Smileys/smiley_cool_test.png" > * It "could" be somehow automated with triggers... but if you really need that, you are better served building your own tool on top of Plastic and doing all the cloaking/uncloaking behind the scenes (we have seen this several times by tools teams in big game studios, building their on thing on top of the plastic "cm partial" - telltale did that, to mention one). Ah, interesting idea! But I guess it's too much hassle in our case - it sounds simpler to rather have the artists live with the longer (and generally one-time, anyway) import times in this case. Especially from a developer point of view... x-D *cough* > * We also have something called "transformable workspaces" https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide.shtml?term=transformable#Chapter17:Transformableworkspaces which could help, but again, it is more something you configure once (or often, but not continuously). Very nice, I wasn't aware of this feature! I just tested it and it seems it, in principle, actually does what we want, and even seems to check "rm" commands BEFORE downloading anything from the server. Unfortunately, it's not really usable for our artists at this time, as it must be edited by hand, is not in source control, and can't do wildcards or relative pathes (so every path for every model would have to be added manually). > * So, I think you are better served by Gluon + configuration - we can probably add what you need (what we mentioned in http://www.plasticscm.net/topic/20563-selectingdeselecting-many-directories-with-gluon/?tab=comments#comment-38151) or, at last resort, some sort of script on top of "cm partial" to do what you need (like a small program or something). That sounds very promising, thanks! And I might also have a closer look at "cm partial" as well. So far we didn't have the need to use the CLI, but it's of course much more powerful than "just" the GUI/client.
  5. Selecting/deselecting many directories with Gluon

    Yes, that's exactly it! A wildcard or search patten for files/directories.That's great to hear, thanks a lot! :o)
  6. Last week
  7. This may or may not be relevant: Some source code comparison yields that in the Plastic SCM plugin, the older code in Workspaces.java uses the Hudson API function FilePath.createTextTempFile(). It places files in locations like "/var/lib/jenkins/workspace/Tests/TestLightWeightCheckout@script/PongSP/selector7941601814195684624.txt". However the newer code in PlasticSCMFile.java uses the native Java API function File.createTempFile() which will place files in the system's default temp folder. There might be permissions problems with accessing the system-default temp folder when Jenkins runs things. In any case, it would be cleaner if the PlasticSCMFile code also kept its temp files in the Jenkins-designated temp file area.
  8. Hi, I'm testing the Lightweight checkout feature. I have created a new Pipeline project (it is more or less a duplicate of an existing project) with "Pipeline from SCM". When I try to build with Lightweight checkout off, it works, but with Lightweight checkout on, I get the following error messages in the Jenkins log: /var/lib/jenkins$ tail -n 12 /var/log/jenkins/jenkins.log Apr 20, 2018 8:24:29 PM com.codicesoftware.plugins.hudson.PlasticTool execute WARNING: The cm command 'checkselectorsyntax' failed. Retrying after 500 ms... (1) Apr 20, 2018 8:24:30 PM com.codicesoftware.plugins.hudson.PlasticTool execute WARNING: The cm command 'checkselectorsyntax' failed. Retrying after 500 ms... (2) Apr 20, 2018 8:24:31 PM com.codicesoftware.plugins.hudson.PlasticTool execute WARNING: The cm command 'checkselectorsyntax' failed. Retrying after 500 ms... (3) Apr 20, 2018 8:24:31 PM com.codicesoftware.plugins.jenkins.PlasticSCMFile getRepObjectSpecFromSelector SEVERE: null Apr 20, 2018 8:24:31 PM org.jenkinsci.plugins.workflow.job.WorkflowRun finish INFO: Tests/TestLightWeightCheckout #4 completed: FAILURE Apr 20, 2018 8:24:31 PM org.jenkinsci.plugins.workflow.flow.FlowExecutionList unregister WARNING: Owner[Tests/TestLightWeightCheckout/4:Tests/TestLightWeightCheckout #4] was not in the list to begin with: [] The Plastic SCM plugin then throws this error: https://github.com/jenkinsci/plasticscm-plugin/blob/931952b1b7903dc3fce22bc7cb392317d90e8e2d/src/main/java/com/codicesoftware/plugins/jenkins/PlasticSCMFile.java#L111 And the 'cm' version: /var/lib/jenkins$ cm version 7.0.16.2143 Now, I don't know how to intercept and capture the exact CM command and its result. Enabling debugging at level 'debug' for cm.exe according to the article only gives me these corresponding messages for one of those 'cm checkselectorsyntax' invocations: 2018-04-20 20:35:00,772 INFO 1 cm - STARTING CLIENT 2018-04-20 20:35:00,971 DEBUG 1 ClientConfig - Time l2018-04-20 20:35:01,046 DEBUG 1 ClientConfig - Time loading client.conf (/var/lib/jenkins/.plastic4/client.conf) 238 ms 2018-04-20 20:35:01,086 DEBUG 1 cm - IsOutputRedirected: [Redirected] Here is what the configuration looks like in the Jenkins project configuration page: Selector: repository "PongSP@<organization>@Cloud" path "/" smartbranch "/main" Use update: yes Workspace name: PongSP Script Path: PongSP/Jenkinsfile.Windows OS version: /var/lib/jenkins$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial
  9. > Just adding "*.jpg" to cloaked.conf will work for existing assets, > BUT it will prevent any future *.jpg that is added from showing up > in Pending Changes (so it can never be committed!). [pablo] Well, yes, just to make it crystal clear, the goal of cloaked is: * Don't download stuff in cloaked.conf (great for avoiding big stuff). * If you have something in your workspace already, don't bother updating it. So, it is not a bug or anything, it is *meant* to work this way. > As I understand, the workaround is to temporarily remove the cloaked.conf > entry, which makes new (and changed) files appear in the Pending Changes. > However, even then it's rather complicated to have our modellers open a > text editor to manually aund temporarily modify this file (or remember to > do this via the right-click context menu). [pablo] Yes, editing cloaked.conf this way is definitely crazy for modellers (or anyone). Not meant to be used this way, definitely. > In the real world, this will get forgotten (which results > in textures not being committed, and this missing from the repo), > or the modified cloaked.conf will be accidentally be committed > as well without noticing, forcing all users that update to > involuntarily download all textures - which is exactly what > we're trying to prevent. Or they will forget they have a locally > modified cloaked.conf - which also forces a download of all > previously cloaked textures on the next update. [pablo] Yes, I agree. > With Unity, having the *.meta-Files in sync with the main > assets is also vital. [pablo] Not sure if you knew this, but when you checkin, Gluon always warns you if the associated meta is not selected. Not sure if it is related, but thought it was good to mention. Unity plugin also does it, but we built this into Gluon too. > In the real world, people will forget to also add/remove > the *.meta-Files from cloak, leading to problems that are > difficult to trace, and which can cause dangerous > inconsistencies (=multiple IDs for the same object, > lost references, ...) [pablo] Agreed. > - Not adding a catch-all "*.jpg" to cloaked.conf, but instead > commit the textures normally, and only then add them explicitly > (or their directory, which is usually unique per model and > contains all relevant textures) seems another way to go. > However, again, people will - per definition - forget they have > to modify cloaked.conf as well after changing/adding a model. > Also, this approach seems to require TWO commits per change: > first, commit the model with all textures, THEN modify cloaked.conf > (as the new textures cannot be committed if they are already covered by cloaked.conf). [pablo] Yes. > - More importantly, it seems impossible to locally update or modify > any assets that are listed in cloaked.conf - at all. I couldn't > even get the "cm.exe upd --cloaked" workaround to do that. > And here, even the "locally modified cloaked.conf" is not > working - even when removing these files from cloaked.conf, > they are still invisible for updates. [pablo] I don't follow this last part: I will double check if cm update --cloaked is broken, but it sounds weird. Finally: * Definitely cloaked.conf is not meant to be continuously edited this way. * It "could" be somehow automated with triggers... but if you really need that, you are better served building your own tool on top of Plastic and doing all the cloaking/uncloaking behind the scenes (we have seen this several times by tools teams in big game studios, building their on thing on top of the plastic "cm partial" - telltale did that, to mention one). * We also have something called "transformable workspaces" https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide.shtml?term=transformable#Chapter17:Transformableworkspaces which could help, but again, it is more something you configure once (or often, but not continuously). * So, I think you are better served by Gluon + configuration - we can probably add what you need (what we mentioned in http://www.plasticscm.net/topic/20563-selectingdeselecting-many-directories-with-gluon/?tab=comments#comment-38151) or, at last resort, some sort of script on top of "cm partial" to do what you need (like a small program or something). Thanks! pablo
  10. Selecting/deselecting many directories with Gluon

    Hi Wolfram and Mikael, Wolfram, I was talking to the team to try to find out the best solution. I think we are close to have exactly what you want: basically you want to be able to select what to load in Gluon based on a given pattern. So, it would be great if you go to Configure, select something (like *.jpg), and then have a button or something saying "select to load", so when you click it, you go to "configure back" and you can apply the configuration. Sounds good enough? pablo
  11. After more testing, it turns out that: - I had the Plastic Change Tracker installed, but the Plastic GUI client was not configured to use it - These problems happen with the regular "move detection" logic in Plastic, but not when the Change Tracker is active (because the Change Tracker will listen to filesystem-level operations, and see the filesystem-level move) - These problems do not happen when using the 'cm mv ...' console command, as that performs a move + logs the move operation with Plastic at the same time Lessons for me: - Ensure I and colleagues have the Change Tracker installed and active (following instructions in the 6.0.16.1151 release notes document) - When problems arise, use 'cm mv ...' to perform the moves
  12. Hi all, A new release of Plastic/Jenkins plugin with the 'lightweight checkout' feature is already available (2.13). https://plugins.jenkins.io/plasticscm-plugin Thanks for the report. Best regards, Míryam
  13. Plastic 7.x incredibly slow?

    Hi, We would like to get connected to debug your scenario. I've sent you an email. Regards, Carlos.
  14. Hi, We are also in contact with Mikael debugging the issue via regular ticket. When refactoring/moving folders in your workspace, it will be a good idea to enable the Plastic Change Tracker service for Windows to precisely track file moves and renames beyond heuristic guessing. https://www.plasticscm.com/download/releasenotes/6.0.16.1151 It seems this service is still not properly working for Mikael, so we will update this ticket when we know what was the problem and we have all the details. Regards, Carlos.
  15. Selecting/deselecting many directories with Gluon

    Hi Mikael! Thanks for your great response! It contains many vital concepts how a team can work efficiently on Unity projects using Plastic, and in fact we already do almost everything exactly as you describe, from using the full client (even for our artists) to branches and task-branches (depending on the project, and the phase of the project), and to asset sizes. The only difference seems to be that we do have the Unity/Plastic integration enabled (although we don't use it, we only use the client), to have the benefit of Unity automatically adding stuff to the repository, marking files as checked out, and so on. And for our source assets we use an in-house file server, which avoids having to constantly up- and download GBs of data, and which also helps with customers with privacy concerns/NDAs. But I guess I didn't make myself very clear in my original post: For regular Unity projects, this approach is great. However, we're thinking about creating some kind of model library, which is a Unity project that just contains tons of models (and textures), and nothing else, except maybe a small tool to better browse/review these models. So we have hundreds of models, each with textures and materials, and if somebody is looking for a specific model, he can download the repo and browse the data. Here, for a quick interactive preview, it's fully sufficient to just have the .fbx's available, so we're looking for a good, usable, maintainable method to NOT unnecessarily download x GB of textures from the repo, which then have to be imported by Unity, which takes "ages" even with a configured Cache server. Instead, the artist should be able to download the textures for specific models on demand. Gluon sounds like the right tool for this situation, but as the textures must be located in a subdirectory next to each model (and IMHO no other simple approach makes sense), we have as many texture directories as models, and AFAIK Gluon cannot multi-select these automatically, for example to prevent the initial download from the repo. We also looked into using cloaked.conf instead (see ), but this approach has many other problems and shortcomings, so it's not really usable for this, either.
  16. Replication of projects with Xlinks

    Subtree branches sounds intriguing. It will be interesting to see how that works in practice
  17. Plastic 7.x incredibly slow?

    Some more infos: - I do remember having seen something about pending changes performance in the changelogs, maybe it's related: 7.0.16.1930 "The pending changes view performance was severely degraded when there were tons of changed items in view. This was broken when the tree mode ("view items as a tree"). It was only appreciable with tons of pending changes. Now it's fixed." - there is no difference whether I switch to tree view or use list view - toggling "Show changes grouped by changelists" also has no effect
  18. Plastic 7.x incredibly slow?

    Hi Pablo! Thanks for the quick response! I re-checked with two of our projects, and re-installed 6.0.16.1765, and then 7.0.16.2082 again (we didn't test/use any versions in-between), and there is a clear (and big) performance drop with the newer version. I created a screencapture for each case: https://drive.google.com/open?id=1G9CQZrPvco7-KO1ZgPTbE02cQNqHa2DQ I changed nothing between re-installs, and no Unity or VS (or other CPU hogs) were running during the recordings. Hope this helps, please tell me if I can be of further assistance in tracking down this problem! Cheeers, Wolfram
  19. Plastic 7.x incredibly slow?

    I found the issue that slows down the properties update It will be fixed in the next release. Thanks and sorry for the inconveniences. Violeta
  20. Plastic 7.x incredibly slow?

    Hi again, We see the Branch Explorer is slower, and @vsanchezm confirms is not a threading issue. She's going to look deeper into it. Now, we are NOT able to reproduce the most important problem: slower pending changes. We are unable to reproduce it (which matches with our belief, because we didn't make changes on that area, although we might be mistaken). Perf is high prio for us, so any other feedback is welcome. Thanks, pablo
  21. Plastic 7.x incredibly slow?

    Yes, we moved out requests from the main thread in 7.0.16.1944. But, the server call done to update the "Properties" panel when a changeset is selected in the branch explorer didn't change. Maybe we could see anything else in the logs. Anyway, I will check it in more detail in case it's affected by other change...
  22. GitSync does not like replicated Plastic repos

    Codice Software have confirmed that this is a limitation of the current GitSync implementation. We have a problematic situation because of all these factors: 1. We are using Plastic Cloud and not Plastic Server 2. We have open source software as part of our main product 3. We have the open source portions in separate Plastic Cloud repos 4. We have xlinks from the main product Plastic Cloud repo to the open source Plastic Cloud repos 5. We use GitSync to sync between local Plastic repos and GitHub repos 6. We have more than one developer who wants to perform GitSync on (replicated versions of) the same Plastic repo 1+2+3+4+5+6 = we run into the above problem. What we are going to do is, we will move to a GitHub-centric workflow for the open source software: Developers will work directly in Git, or, if they want to, they can create local Plastic repos and use GitSync to be able to work on the project using Plastic. These local Plastic repos will not be replicated anywhere, particularly not to Plastic Cloud. They can be considered throw-away repos; the source of truth will be the GitHub repo. We will also stop using Xlinks. Instead, we will update the opensource projects within our product by copy & pasting in files. We will lose the detailed versioning in that step, but we avoid all the complexity that Xlinks bring.
  23. Not a fan of the new Branch Explorer UI

    Hi @nqramjets, Thanks for reaching out! Ok, we can change the default color for the merge links. I don't like the pastel one either :-P. Now, on the selection color: for ages we just used some blending. You know what: almost anybody understood it. Now multiselection is quite clear, and selection is also in most cases. I understand the best option is to enable custom colors for more elements. Would you guys mind sharing this in our UserVoice and proposing something as specific as possible? Thanks! pablo
  24. Plastic 7.x incredibly slow?

    Hi Wolfram, We're shocked by this slower pending changes, and we have been checking since we received this 3 hours ago. @ruben, @Borja and I are looking into this. Regarding the slower update in Branch Explorer: this can happen because we moved out requests from the main thread, to avoid the GUI hanging. I'll check with Violeta if we can reduce the wait time.
  25. Feature request: changeset numbers in branch explorer

    Hi Wolfram, Just took note of your request for the next SPRINT. I'm not 100% sure we can make it, but we'll do our best to push it Thanks for the great feedback. pablo
  26. Selecting/deselecting many directories with Gluon

    Hi Wolfram, just to give you some ideas on how you could work: We are also working on a Unity3d project. 12 devs (6x art, 3x code, 3x design) We keep source-format assets on Google drive, and only game-ready content (fbx tga and so on) + game source code in Plastic. The latest working copy is ~5GB in size for us. Everyone on our team uses the full Plastic GUI client (not Gluon). We chose the full client because it allows working with branches. Most people started out working directly on main, then I trained them to work on personal branches, then I trained them to work on task-based branches. Today 70% use task based branches, and 30% use personal branches. The Branch Explorer is a good enough graphical view for all disciplines to understand this way of working. We do not use exclusive checkout. We do not use the Unity/Plastic integration. We force meta files visible and force text format for all assets. We pay lots of attention to making our data files small and mergeable (including extensive use of prefabs just to move stuff out of scene files). We avoid situations where we need to merge scene files through communication & coordination. This works very well for us so far. In the future, if Plastic's roadmap allows for quicker check-ins of large datafiles & "nodata replica" workflows improve, we may consider moving our Google Drive content to Plastic (either into the main game repo, or into a parallel repo).
  27. Hi, I recently tried establishing a workflow where we publish one of our projects on GitHub. We would do the primary development in a repo in Plastic Cloud. The idea was that developers would replicate the Plastic repo to their local workstations, develop there, and then run GitSync to update the public version of the project. However -- when using GitSync, Plastic will store the GUID of the first Plastic repo used in the Plastic repo's metadata. This information will then be uploaded to Cloud at the next push, and fetched by other developers when they pull. When the other developers attempt to use GitSync, they will get an error message: The sync cannot start because the target repository was replicated from a repository synchronized with git. The repository originally synchronized is 'GitHubTest1@local - https://github.com/Kalmalyzer/PlasticGitHubTest.git'. Please contact support for further info. This means that only the first developer who used GitSync can perform the sync. Worse yet: if the developer deletes his repo and recreates it and replicates from Cloud, noone on the team can use GitSync any more. Am I missing something vital here?
  28. I have attempted to replicate this on a different machine (repository replicated machine1->cloud->machine2), but the problem did not occur there. Therefore I suspect it will be difficult for me to provide you with a repository dump that you can use to replicate the problem on your side.
  1. Load more activity
×