Xarbrough

In the previous GUI I could click on the little arrow/cross icon between the two columns of the diff in the pending changes view to undo this specific change block. I used this feature all of the time, please bring it back! In the newest version of PlasticX this seems to be replaced by a feature that allows me to open this change block in a separate window, which I don't find useful at all. What is the use case for this? It was already possible to open the file in a new tab previously in case I wanted to save the diff for later, but I feel like focusing in on just a single line doesn't add much, especially if I lose the ability to easily undo accidental changes. For example, I would often do some experiments in code, maybe accidentally format something, then implement the fix and cleanup the script in Plastic simply by undoing everything but the actually relevant lines of code, which makes for clean checkins.

In most software (text editors, windows explorer, browsers), the keyboard shortcut CTRL + A will perform "select all". In the pending changes view however it now does "Annotate" which not only goes against this common convention, but is also a deviation from the original behaviour of the PlasticSCM GUI before PlasticX. In the old GUI, CTRL + A would select all rows of changes in the pending changes view, which made it easy to then context click to undo for example. Is there something I'm missing here? I might need to adjust my expectations, but I constantly press CTRL + A expecting all rows to get selected.

It would be immensely helpful to not only see that invisible characters have changed, but also which characters. In the old UI spaces and tabs were indicated by dots and tab symbols, but this is missing in the new UI. Also, the addition of showing end of line characters (CR LF) would be great, because we often deal with accidental changes that need to be reviewed quickly. Currently, I always have to open both versions of the files in a separate text editor to check which line endings or tab/space convention is used and which should be the correct one.

Yes, my issues are solved, thank you! One thing I discovered earlier was that some parts of System.Web were not found when I used .NET target framework 4.7, but I simply downgraded to 4.0 and replaced the dependencies to make it compatible with PlasticX. I assume Plastic doesn't promise any specific environment other than the oldest .NET 2.0 (because only that one is mentioned in the documentation), but it looks like .NET 4.0 is fully supported by the old and new clients.

Turns out: I accidentally created the Xlink as writable. Even though I didn't try to modify repo B it still seems to have issues with the missing permissions. In this case I could simply delete the Xlink and recreate it as truly readonly, and then I was able to download and merge from the other repo without additional permissions.

On repo A I created a new feature branch, then added a readonly non-relative Xlink pointing to repo B. I developed some feature on my branch and now I want to merge to main, however I'm getting permission errors which I don't understand: - Missing permision "mergefrom" - Missing permission "ci" (checkin) Currently, I have full permissions for repo A, but only read and view on repo B (because it's owned by a client and I have no control over it). Why do I need checkin permissions on repo B to be allowed to merge and checkin on repo A if I already have read permission for repo B? It seems like the checkin permission would control checkins to the repo the permission is set on, but apparently Xlink permission propagate when used in another repo. How can my client and I fix this setup? They want to prevent me from modifying repo B directly, but allow me to use it as a readonly Xlink in my own repos.

I've previously built a custom extension for the standard GUI. It's a .NET library project which references not only the issuetrackerinterface.dll, but also log4.net.dll and utils.dll because they also contain code which I depend on. When I deploy the extension, I only copy my single plugin dll to the extensions directory, because Plastic automatically loads the additional libraries. Not sure if this is the best way to handle things, but it used to work correctly with the old GUI. In the new beta GUI, my extension loads correctly (even though it can't yet be configured in the preferences), but it throws runtime errors indicating that certain assemblies couldn't be loaded. For example: "utils" or "System.Web". The first is actually part of the PlasticSCM client folder, so I wonder why it's not loaded. The second is part of .NET, but I'm not sure why it's automatically present when using the old GUI but not loaded with the new one. Is there a better approach to handling these dependencies for me? Or will PlasticX add the missing assemblies in the future? Of course it seems like I could simply copy paste all of my dependencies into the extensions folder, but I'm afraid this may cause conflicts in the future, when Plastic evolves and might upgrade things like the utils library or log4.net, but again, not sure what the best approach might be.

Good progress, nice!

Can you maybe elaborate why it doesn't work for you to specify the merge tool per file extension in the preferences? I believe having it per file extension is already much better than e.g. in Git where you can only chose between builtin or use a custom one which you have to specify via the commandline before every merge. For example, my team uses Unity and has the UnityYAMLMerge tool configured as Plastics merge tool for .prefab and .unity files. Do you mean you would like to regularly switch between multiple merge tools for the same file extension? Which use case is that? In my limited personal experience, merge tools work pretty much the same unless they deal with custom formats such as YAML or JSON where it's important to keep the syntax intact when merging.

Today I wanted to checkin a file with a relatively long line and got this error message: That shouldn't be an error, its a valid file. Ideally, UI and performance are both optimized so they can display arbitrarily large files. If one of these goals is too difficult to achieve in a reasonable time, then at least the error should be handled and displayed with an unobtrusive message on the diff view stating "the file contains lines which are too long to display here". I have also attached the offending file. It's a Unity scene meta file which contains custom user data (in this case, a serialized preview thumbnail). It's not too uncommon to have files which are human readable (diffable) such as Unity YAML or Json and also have some blobs of binary data within those text files. Just think of JSON with custom payload or YAML with inline images. Platform: Windows 10 Client: 10.0.16.6307 Camaron De La Isla Thank you! Edit: I also tested in the regular (non-PlasticX) client and there the error does not show. It correctly displays the long line in the diff view without any issues. UI.unity.meta

The "Explain Merge" feature seems to be missing from PlasticX. I hope you will bring it back soon, as I use it often and find it very helpful to double-check the merge and be sure about what source and destination is (since that can change depending on whether I merge from the current branch to main or if I set my workspace to main and then merge from the branch).

In the diff view "Comparing previous content with revisions": I would like to context-select an item and chose the option "Show History" or "Annotate". This would make it easier to review changes, because this usually starts in the branch explorer or changesets view, then I double click a changeset to open the diff view and select a file. If the current diff does not answer my question I often would like to check the history of the specific file and see if the offending change was made a couple of changesets earlier for example.

The commandline has the cm undelete command which is able to locate and restore a specific file that was deleted. I would like to have the same option but using the GUI client: Find a file that is no longer part of the workspace and repository (because it was deleted/removed and the changeset was checked in some time ago) Undelete/restore the file to the current workspace and show it in the pending changes tab I know about subtractive merge, which already helps fixing larger mistakes on per-changeset level, but I noticed that in my team we often have much smaller mistakes such as a deleted file, but the changeset that deleted it also contains 50 other deleted files which I don't want to restore. So it would be perfect to do this on a per-file level. Ideally, the history would be kept alive as with subtractive merge, but if that doesn't work, it would be good enough to at least re-introduce the file without any history.

What are your PC settings and which platform? I assume that Plastic uses whatever you have configured in e.g. Windows Regional Settings. At least on my machine with Regional format English (Germany) it looks correct: It doesn't really make sense to have different regional formats per application, does it? Would only confuse if it weren't consistent. But of course, maybe the Plastic client is bugged and doesn't use the correct regional format of the operating system.

Thanks, here's our current list. It's not exhaustive but only the most common which we use in our day-to-day work. Almost all of them are serialized as YAML, which is a plain text format and looks very readable, so that's why I was wondering why the auto-detection even thinks they are binary. filetypes.conf .anim:txt .asmdef:txt .asset:txt .controller:txt .giparams:txt .mat:txt .mat:txt .meta:txt .mixer:txt .overrideController:txt .physicMaterial:txt .playable:txt .prefab:txt .scenetemplate:txt .shader:txt .shadergraph:txt .shadervariants:txt .signal:txt .spriteatlas:txt .unity:txt .uss:txt .uxml:txt LightingData.asset:bin

I noticed that Plastic often doesn't display a file revision diff, because it thinks the file is binary, like this: For this reason, I started configuring the filetypes.conf file, which works correctly when I add the entry and restart the client. However, I'm wondering, wouldn't it be possible to improve this auto detection for files within Unity? In our case, almost all files in the Unity project are text files, because they are all serialized to YAML, which makes them human readable, diffable and mergeable. I often like to see what changes I exactly made to prefabs or ScriptableObjects and I can check in the YAML in the pending changes view. But the detection issues seem to mean I have to setup every single file type. Is this really necessary or is there a better way? Either for me configuring things or for Plastic developers to improve the detection maybe with some assumptions about Unity projects?

Maybe I'm not understanding how to use it correctly or the feature might be in a different build version, but I also checked with my coworkers (also working on Windows 10) and none of them can get horizontal scrolling to work. ShiftScroll.mp4

I'm using Windows 10 (tested on two different PCs). PlasticX build 10.0.16.6307. When I zoom into the branch explorer until both scrollbars show, I can scroll up down with the mouse scroll wheel. If I hold left shift (or right shift) and use the scroll wheel at the same time, it still only scrolls up down, but not left right as expected. I tried other modifier keys like CTRL, but that triggers zoom and ALT does nothing.

Release version : 10.0.16.6307 Camaron De La Isla OS: Windows Steps to reproduce : See the attached video. Open the Pending Changes view with multiple changed and deleted files. Click the toggle next to the "Item" label to select/deselect all. Real result : A single click on the toggle will open the Differences view every second time. Sometimes a error popup shows. Expected result : The toggle should only toggle the selected state of all sub-items. Relevant lines from the log file: 2021-11-25 13:09:13,250 CHRIS\chyarbrough ERROR ExceptionHandler - [plasticx] Unexpected error: Object reference not set to an instance of an object. 2021-11-25 13:09:13,250 CHRIS\chyarbrough DEBUG ExceptionHandler - Stack trace: at UiAvalonia.Exceptions.EventProtection`1.Event(Object sender, T e) No other stacktrace was logged. ToggleItemsOpensDiff.mp4

I'm not sure if the jitter/choppiness can be really showcased in the video, but the inertia doesn't look as smooth as other software I'm currently using. Not a big issue though of course. Just some nitpicky polish. I feel like the implementation of the inertia uses only the last delta frame of movement, but that results in weird stopping or super fast jumps sometimes. A smoother implementation would probably average multiple frames of velocity and smooth out sudden spikes to make it feel softer. Now that I played around with the feature, I do have to say that I do like the idea of panning with inertia, it just could be a little smoother for mouse usage (I assume it feels much better with a large Apple trackpad for example). Panning.mp4

Thanks for letting us know! I understand that touchpad support might be relevant to the user base and I would be ok with using the shift key. However, using shift and mouse wheel doesn't seem to work. I can hold CTRL and use the mouse wheel to zoom in, which is nice, but shift simply does nothing. Also, I like the idea of the drag to pan around in the branch explorer. I believe I'll use that a lot in the future. However, I must say it doesn't feel "super smooth" at all. It's rather choppy as if it had an unstable low framerate. Especially when I drag and let go, the inertia effect after mouse up looks very jittery. If that is also due to the framework implementation I'd prefer no inertia at all and just have tight panning control with the mouse. There's nothing suspicious showing in the log, I'll try to record a video. Build 10.0.16.6307 Camaron De La Isla

I regularly (multiple times per day) drag the diff view section at the bottom around so that I can either have room to display more items in the item list or see more of the diff content. Basically I feel like I always toggle between looking at the entire pending changes list or I want to diff files. So, here's my feature request: Provide a button and keyboard shortcut to toggle the diff view so that I can focus on the entire list and switch to diffing quickly.

Release version : 10.0.16.6280 Cass Elliot OS: Windows Steps to reproduce : Select the "Only relevant" button in the Branch Explorer. Then select a changeset. Now toggle the only relevant button off. Real result : The view jumps to a point in the past and the selected changeset is no longer visible. Expected result: The Branch Explorer view should stay focused on the selected changeset or the "home-changeset" (current workspace location), if nothing else is selected.

Release version : 10.0.16.6280 Cass Elliot OS: Windows Steps to reproduce : Modify multiple files in the repository. In the Pending Changes view, select some, but not all of the changes and checkin. Real result : The selected files are correctly checked in, but the pending changes view does not refresh and still shows the selected files until the manual refresh button is pressed. Expected result : The pending changes view should always refresh after a checkin to avoid the confusion that the checkin might have not worked correctly.

At the bottom of the new UI there is a blue bar that seems to be reserved for showing different kinds of status messages, notifications and alerts. I already mentioned in my first impressions thread, that I believe this draws too much attention to the bottom of the UI and also mixes different concerns that may be better separated. Here's another example: If I delete all text in the comments field, the bar turns orange and displays a message. I see multiple issues with this design: The notification is really far away from where the "issue source" took place. Both the text field and the checkin button are at the top, but the info message is at the bottom. I see the benefit of onboarding users or reminders, especially in the Gluon interface, however I would rather treat them as "tips" or "tutorials" and make such messages optional. After multiple years of practice or more generally advanced users in the full GUI, I doubt that everyone can appreciate this message. There should be some dedicated room for tips/tutorials/actionable info close the where the info is needed. Maybe in the form of a larger tooltip popup (non-blocking). Some of the messages, such as about server maintenance, would fit better in a dedicated notification area, maybe with a bell icon on the top right. Some of the messages such as "ready" or simple status updates like "loading" are not really helpful. If the UI is blocked during loading, the UI itself should show that it can't be interacted with, there are loading bars etc, so no need for the simple text line at the bottom in my opinion.