Xarbrough

Do you mean this one? Which kinds of queries do you use here? Are advanced searches supported here?

The new font looks a little blurry for me (full HD monitor) as well, but on the other hand, old plastic may look a tiny bit too sharp-pixelated. Fonts are tough. But the blurriness is most noticeable with bold text, look at the letter 'e' in this screenshot, for example: This is original size and you can see how the e is almost a blob, as if the normal font was artificially bolded in code instead of having its own type face. Larger size:

Just some more minor things here, I'd open new threads for bigger usability issues. In Branch Explorer please re-implement the scroll direction to match the branch layout. Previously, when the branch layout was horizontal, using the mouse scroll wheel would scroll horizontally and when branch layout was vertical it would scroll vertically. In PlasticX it always scrolls vertically, but it makes total sense to align the scroll direction with the time axis of the graph. The home icon on the branch which indicates the current workspace position is really noisy (has to many small details) I believe. The following screenshot is on my 1920x1080 monitor in what I would consider common zoom level. The same goes for the changeset bubbles that indicate an outgoing merge link (multiple thin border lines). About Branch Explorer "display full branch names" and "display branch task info": We use these settings because we follow the recommendation of naming branches like "/main/abc-123" and then "Some Task Title" as the comments field. We currently use a task ID for the branch name and the readable task title, so like to see both in the branch explorer view, but the info "main" is usually not needed, because everything (for us) is rooted in main. Maybe the convention isn't perfect, I'd be open to change it, but I believe the options are still useful to declutter the graph view.

First, thank you for providing us with the revamped GUI! My name is Chris, I'm a programmer at Nementic, a game studio based in Munich. We use Plastic SCM and Gluon to version control our Unity projects with 10 users. Things I like Tabs are now only on the left and fixed, this is perfect, since moving tabs around wasn't really helpful and sometimes was confusing. Switching between dark and light themes is awesome! The new overall style seems coherent and fits Unity's style well, which I personally enjoy. The branch explorer smooth zooming is nice and overall rendering looks good. The top right burger menu (for theme switching), preferences and user account display is great. Overall, the UI looks a little cleaner, which is a good thing as long as all needed options are still present (or will be re-added later, for that matter). The "Switch workspace..." button now opens a separate window that displays more information about workspaces and repos, that's useful. Things I'm missing In the Branch Explorer, the option to color changesets by user. In the Branch Explorer, the option to show full branch names and hide the "main" prefix. The keyboard shortcuts to switch between tabs are missing (CTRL+1 for workspace, CTRL+2 for pending changes and so on). Things I dislike Syntax highlighting of C# scripts looks like it wasn't yet correctly implemented in the dark theme. The bottom blue bar in the main window draws too much attention. The "Ready" text seems like noise to me. I understand it might be a place to display info such as "loading" or even notifications like "server maintenance expected on x" but I feel like status messages should be subtle (not bright blue) and notifications deserve a button in the header bar (e.g. bell symbol next to the user name, close the preferences), that when clicked, shows a popup with notification messages, that can be dismissed. Icons in the preferences window tab header are difficult to read (dark blue on gray). The "Switch workspace..." button position is strange in the bottom left. I would expect it on the top left, next to the changeset number display, because that bar already shows the info about "where" my workspace/repo is. The button at the bottom bar seems to take up useless space. I realize that many features are probably work in progress or not fully implemented, so I'm looking forward to those, but still wanted to mention them to show some sort of first-glance priority of things I noticed when I started using the new UI in my daily work. Again, thank you and keep up the great work!

My team is working mostly on Windows 10. Two of my colleagues and I would be happy to try out the dark theme and give some feedback, report issues, if any.

Hi, thanks for looking into this! Can I send you a private message with attachments or reach you directly via mail somehow? I have a video or could also provide logs, if that is helpful. I can reproduce this issue the following way: - Checkout a working copy of a git project via git tools - Migrate the git project to Plastic SCM via fast export fast import - Checkout a working copy of the plastic project to a new location - Now there are two project directories which should have "equivalent" content (same file contents) Now, if I copy paste a directory of multiple (!) files from the git working copy to the plastic workspace, the file shows up as modified but identical. Of course, I have the setting "check content" enabled, which seems to work fine in other cases, e.g. when I only paste a single file it doesn't seem to reliably happen, but it does if I copy paste an entire folder. EDIT: I'm not using the Unity plugin, only Plastic SCM full GUI.

I found this interesting and wanted to try it myself, but ultimately didn't succeed. However, if anyone wants to pick up where I left: The blog page describes how to setup a basic image preview generation program, however blender is a little more complicated because it needs to first open the .blend file, then create a preview scene and render that to a file. Luckily, there seems to be a python utility exactly for this purpose. You can invoke it like this: "E:\blender\blender.exe" --background "PathTo\Fairy.blend" --python "E:\blender\2.93\scripts\modules\bl_previews_utils\bl_previews_render.py" We can try to use this to setup a preview tool in plastic, since it provides the "@src" variable which points to the .blend file. However, now comes the issue: Plastic expects us to pass on the "@output" path and let our preview utility render to that file path. As far as I could tell, the python script is hardcoded to only render to the temp location and doesn't accept any file path argument. I've also tried setting the blender.exe output path, but it didn't do anything in this case. So I guess some options would be: - implement a custom python scripts that's basically a copy of the default one with the option to provide a custom path - ask the blender community to do that - hack around at trying to get the temp path and copy the image over to the plastic output directory I went so far as to try changing the default python script, however it then complained that "file format not supported" which simply referred to the path of the temporary preview file being "something.tmp" instead "something.png". At this point I gave up, because I'm not sure I can make the image library accept a path that doesn't have the "correct" file extension.

If the asset files are automatically recreated after a compile, I would definitely add them to the ignore.conf. To make this maintainable you could simply add a special extension for them like MyAsset.generated.asset and then ignore all files that contain ".generated" for example. You can also do this in one go, by using the workspace explorer in Plastic Full GUI. Context click the file that was already added and simply select "Delete". You can then update the ignore.conf and checkin your changes. It will show all of the files as removed and the ignore as modified and with future checkins, those files should be ignored. You can even automate this by using the commandline if you followed the recommended naming convention. Just find all .generated files and their meta files in Powershell and call the cm rm with the file paths. If you don't want to make such changes to the project at this time, you could also simply try the preferences option "Check content (hash) when the file timestamp is modified". Which should let Plastic actually diff the content of a file. That would at least only show the files if their content has actually changed.

Ok thanks, that works! It took me a little while to understand but I think I undestand this now: ^/abc_[0-9].txt$ will match abc_0.txt but not Assets/abc_0.txt which is what I want. ^*abc_[0-9].txt+$ will match both files because the star is like "any path" I still don't really understand why ^abc_[0-9].txt$ doesn't work, because I don't have to start other file patterns with a slash either and its also a fully valid regex expression in other tools I'm using.

A philosophical question if I may ask: Will this feature be intended to support the concept of monorepos? It seems like a lot of big companies are using a single huge repo instead of many smaller ones because it makes dependency tracking and code sharing easier, so our company is considering this as well for the future. So far, however, it seems if you're not Google, you can't afford the infrastructure to support such large repositories, especially if they also need to work with remote working nowadays. So, would you say this will make a monorepo feasible for e.g. indie game studios that are using Unity and maybe share a dozen or so projects and a team size of 20 people?

In my personal circumstances, I like to use my company account for everything, business and private projects. We also work with clients who have their own Cloud organization and invite our team users, because it makes it easier to manage credentials if every user only needs to keep track of a single account. Many users will probably have a company and a separate private account, however I believe that it's not that common to switch between them. Many have their accounts linked to specific devices like the workstation in the office or a company laptop at home and a separate home computer, for example. For cases where developers aren't allowed to use a company account for private projects but still work on the same device (maybe home office), it seems like the option to switch a profile should definitely be available, but maybe it doesn't have to be on the top most layer. Somewhere in the preferences sounds like a good compromise.

My team is also looking forward to a dark theme overhaul. We've really gotten used to Unity in dark theme and virtually all other applications as well (GitKraken, Photoshop, Blender) and the old Plastic dark themes really felt out of place or only partially implemented for that matter.

I've enabled the option "Check the content to determine files as changed, not just timestamp". Previously, this would hide files with the same content but new timestamps completely from the pending changes view in Plastic SCM GUI. Especially when working with Unity this setting is important, because Unity like to touch a lot of files without actually changing anything. However, in the most recent version (10.0.16.6241), it seems the option no longer works: I've checked in a couple of files and then copy pasted the same files on top, because I had a few selected manual changes I wanted to port. In this case, only 2 or 3 files should have modifications, but Plastic shows all 237 in the pending changes view. The diff view however correctly states that "Files are identical". Is this some special case I'm not aware of or might there be something wrong?

I'm trying to ignore files by using regular expressions, but it seems like none of the expression work. I looked at the documentation and also tried some simple cases and examples from the docs, but nothing seems to work. For example: I have two files: abc_0.txt abc_1.txt In my ignore.conf the rule: ^abc_[0-9].txt$ But the files still show in the pending changes list. If I put abc_0.txt in the ignore file, it is correctly hidden from the GUI and ignored. Is there something I'm missing or are regular expression currently broken?

Ok thanks! I believe this means, we shouldn't use Xlinks in this case. If our client continues to use MainRepo and we decide to delete UtilitiesRepo, they won't be able to continue working with their copy of the utilities. I'll just copy and paste our utilities manually into MainRepo then.

I have a MainRepo with an Xlink pointing to UtilitiesRepo. The utilities are hosted on my company's cloud edition, but the MainRepo is part of a different organization's cloud. What happens if I decide to delete the UtilitiesRepo or deny access to all users? Will MainRepo still have the last state/copy forever or will they lose access to data that was hosted in UtilitiesRepo? Specifically, if noone has a copy of the repos checked out to a workspace, does the MainRepo cloud repo contain some sort of duplicate data from UtilitiesRepo or will that be lost/broken if the repo is not reachable for whatever reason? We're trying to figure out how to structure our repos for client work where the client wants to have full control over their project repo, but we would like to provide some of our shared code projects during development time. When the project is over, we would like the client to keep the most recent copy of our utilities, but not have access to any future work done on the repository. Or, maybe we want to delete our own repo in the future, but our client wants to be able to build and maintain their MainRepo project without depending on our company, etc.

Usually not something our designers and artists do, they're more of the cautious type, but well that's good info anyway, I'll share it with the team to keep an eye out when updating and seeing any more .private files.

I also wondered this, so this means Plastic should only create .private files (or folders) if these are accidental duplicates not versioned before. However, in our case, I noticed some trouble this week on multiple workstations in our office: Artists and designers were complaining that their projects were completely broken and when I looked at them I found a dozen (one time even hundreds) of private files. After deleting them everything returned to normal. However, there's no way that our developers created all of these conflicts themselves. I asked them about those files and for all of them they said they would never work in this part of the project anyway etc. So it looks like Gluon might be causing private files to be created in some specific situation that seems a little buggy. I can't reproduce this and there wasn't anything sticking out in the logs, but if anyone has an idea what could cause these files other than real conflicts (maybe when switching workspaces or something), I'd like to investigate this further.

Yes, right, the local client debug log and I was using the full GUI. We have 'Region: Europe West - Netherlands' selected in the cloud dashboard and are accessing from our office in Munich, Germany. Our internet connection should be 250Mbit/s download, 25Mbit/s upload in theory, but of course it could be worse sometimes. Here is the result from iostats: cm iostats Nementic@cloud --nettotalmb=128 Performing network tests with server: Nementic@cloud. Please wait... Upload speed = 2,79 Mbps. Time uploading 128MB = 366453ms. Server: Nementic@cloud Download speed = 240,94 Mbps. Time downloading 128MB = 4250ms. Server: Nementic@cloud Performing disk speed test on path: C:\Users\chyarbrough\AppData\Local\Temp\PlasticSCM_IOStats. Please wait... Disk write speed = 180,028129395218 MB/s. Time writing 512MB = 2844 ms. Disk read speed = 3631,20567375887 MB/s. Time reading 512MB = 141 ms. This upload speed looks pretty bad, but it also matches the general purpose speed test I just did: So the speed doesn't seem to be a Plastic issue, but I don't understand the timeout and why it worked on CLI but not in the GUI when I tried 3 times before. Even with a slow connection, I'm fine waiting an hour, if it finishes eventually. But timing out after 40 minutes is painful.

I tried adding a really high value for <SocketConnectTimeoutMillisec>3600000</SocketConnectTimeoutMillisec> but it didn't help. I then performed the checkin operation via the CLI command and this worked fine. Took over an hour because of the relatively slow connection, but succeeded on the first try. So I guess this is no longer a pressing issue for me. But it would be good to know for the future if there's any difference between the GUI and the CLI regarding the timeouts and if this is something we should configure for all clients in the company.

Today I'm trying to port a legacy project to Plastic Cloud. I created a new cloud repo and a local workspace directly connected to it. Then used the checkin option in the regular Plastic GUI. It started the checkin and was uploading almost 6GB of data at a speed of 20 mbps. The remaining time bar said it would take approx. an hour. However, after I returned to the workstation 40 Minutes later, a popup showed "Connection timed out". I've attached a part of the debug log that also shows "Connection timed out". Now, the error also happens when I try again, so I'm unable to push this to the cloud. I'm not aware of any network issues, other repos pull/push and downloads finish correctly. Is there something I can do to workaround this? Is there maybe just some configured time-out value in the config somewhere? plastic.debug.log.partial.txt

Can anyone confirm whether YAMLMerge will work when defining it for .prefab;.unity both in one statement? I’m also trying to make this process easier for my team but so far its tedious. Especially since you can only define a single tool for the entire client, whereas I would prefer to set the merge tool per repository or at least workspace to match the Unity version. Unless Unity would state if there are actually any changes between the YAMlMerge tool versions...

That's so awesome! I must admit, I've read over the documentation but didn't realize the feature existed since it seems to be only CLI, but that's fine!

We have public open source repositories hosted on GitHub and use GitSync to sync changes to a Plastic SCM cloud repository because we prefer working in Plastic and also like to use Xlinks to include the Plastic repo in other repos without relying on Git. Since the GitHub repo is only meant as a public release channel, I would like to only ever sync the main branch, but still create additional Plastic task branches during development. Basically, I'd like to create a lot of Plastic branches, but avoid spamming GitHub with these branches. Is it possible to configure it so that nobody can accidentally GitSync a development branch?

Was support for linking only specific folders of a xlinked repo ever implemented? I have the same use case. We have a repo of shared Unity code: SharedProject Assets ToolA ToolB And then our current main project, where we would like to include only a subfolder of the shared project: MyProject Assets Plugins ToolA* (from SharedProject) As suggested, it would in theory work, to make ToolA and ToolB their own repositories, but then we would have to manage a large amounts of repositories and they would only work when xlinked into another repository that has the Unity folder structure set up around them. What I like about our current SharedProject is that it works on its own to test and develop features inside of it. Also, many of our tools have dependencies between them and its simple to manage if they are all part of the same SharedProject, but would require lots of dependency management if broken apart into different repos. That would be the point where xlinks seem less attractive than a package manager (like NPM), but I was trying to get away from packages because they have their own set of issues.