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