Aki Kanerva

I made a video showing the workflow in TortoiseHg Workbench. Here's a description of how it would have avoided the key pain points I had with Plastic SCM. I've created a dummy project with some text files checked in. For demonstration purposes, the contents of three of these files are identical, to confuse automatic detection of renames. Move files using Explorer to a different folder Switch to TortoiseHg Workbench Perform manual refresh to detect changes in the workspace TortoiseHg now lists four removed files (in red, prefixed with "!") and four added files (in pink, prefixed with "?") I can use two different methods for telling the SCM about renamed and moved files. First, I'm going to show the quick manual method, which has no equivalent in Plastic. Right-click on an added file to bring up the context menu Select "Was renamed from" This brings up a submenu that lists all deleted files I can now quickly pick the correct file from the submenu No automatic move detection is performed at any point - this process would be fast even with thousands of files. Naturally finding the correct target from the submenu would be slow for the user, but I believe the submenu uses some kind of a quick sorting method, perhaps based on filename similarity, because I often find the correct files near the top of the list The second method uses automatic move detection, similar to Plastic SCM. However, this is a user-initiated action on the workspace, rather than being a global preference that must be either on or off at all times - again reducing the amount of unnecessary processing compared to Plastic. Select any number of added files Right-click to bring up the context menu Select "Detect Renames..." This brings up a separate window for processing renames Just like Plastic, I can now adjust the similarity percentage and then run contents comparison. However, unlike Plastic, I am able to adjust the percentage and run the detection multiple times. Each time, it will only run on the files selected in the left pane, rather than all files (which would be really slow). Detection results are listed in the right pane I can now select the matches I want, and manually accept them. If this was a real situation, some matches would have a higher percentage, and these would be prioritised, just like when Plastic chooses the best match. However, unlike Plastic, if the similarity percentage gives the wrong match (for example, a file was both renamed and changed, as happens often with Unity .meta files), I can still quickly fix it by manually choosing a different match. The only way to do this in Plastic is to globally turn off move detection, refresh the workspace, and manually try to find the correct files from among all changes (which are no longer easy to find due to the move detection being turned off). I can keep making matches within this window until I'm satisfied, then close the window Once the window is closed, TortoiseHg will refresh the workspace - in Plastic SCM, the workspace would have been unnecessarily refreshed several times, which can take minutes when there are hundreds of moved files. Hope this helps clarify the workflow that is missing from Plastic. tortoisehg_detect_renames.mp4

Upvoted!

Hi @M-Pixel, Yes, I know. My issue is that I have 400 files that were moved, but only 6 of them are matched incorrectly by Plastic. I really don't want to turn off "Find moved and renamed files and directories", because then I'd have to manually match the other 394 files. Actually that was one of the first things I tried. But there were two more problems with that approach. First, when I turned off "Find moved and renamed files and directories", I no longer saw which files Plastic matched incorrectly. I had to turn it back on, then write down each mismatched file pair in Notepad, and then turn it off again. Then I used "Search Matches" to manually match the 6 offending files. But when I turned "Find moved and renamed files and directories" back on again, the manual matches I'd made had disappeared. Plastic's automatic matching was overriding the manual changes I'd made. So that turned out to be a dead end. Thanks for mentioning that about the Unity plugin though. I have been using the built-in support all along, but for some reason moving files inside Unity wasn't detected that time. I tried it again, and now it works. No idea why it failed previously. (Although, to be fair, moving lots of files inside Unity is also somewhat inconvenient compared to Explorer.)

That seems like a pretty big omission in the GUI, and a disadvantage over other clients like TortoiseHg. When you use an algorithm to do something automatically, it's a good idea to provide users the option of adjusting the results manually, without having to ignore the rest of the algorithm's results. It's less about the comfort, it's increased cognitive load that easily leads to human errors. There are already two different views into the same files (Explorer and Unity Project View). Adding a third one just makes things even more complicated for users. It's hard to remember what you're supposed to do and what to avoid in each view, and takes mental resources away from the actual development work. It would be great if the Unity plugin could handle this. So when I move files in the Unity Project View, Plastic would detect that as a controlled move. Yes, this is definitely a good idea! Finally, I noticed that if I delete one folder in path A, and create a new folder in path B, Plastic will think that folder A has been moved to B - even if they have different names and paths. It would be great if I could right-click on a detected move and there would be a context menu item to "un-detect" that move.

Hi Carlos, I'm referring to a situation where Plastic detects a move, but it's matching the wrong two files. Here's a simplified example. Let's say I move two files: Assets/Configs/A.txt --> Assets/Resources/A.txt Assets/Configs/B.txt --> Assets/Resources/B.txt But Plastic decides that they were swapped around: Assets/Configs/A.txt --> Assets/Resources/B.txt Assets/Configs/B.txt --> Assets/Resources/A.txt This can happen often with Unity .meta files, because they have little content, so even small changes can significantly decrease the similarity percentage. Moving the files happened to coincide with Unity deciding to change their content unexpectedly. When you upgrade Unity to a new version that has new import settings, they don't get written into the .meta file until much later when the asset in question is reimported or has its import settings changed (which may not happen for months after the upgrade). Moving those files was related to a process that didn't change the assets, but Unity happened to change the .meta files by adding new default values. It's not a big issue if there are just two files. However, in my scenario, there were 400 moved files. Among them were 6 wrong pairs of files. What I wanted to do was accept the other 394 move detections, and then manually fix the other 6. But Plastic doesn't let me do that - after a move has been detected, it can't be changed without turning off move detection entirely. I didn't want to manually match all 400 files. In this scenario, changing the match percentage was of no help either. Increasing the threshold would have left out 200 files. (As an aside, all .meta file similarity percentages were 44% in this scenario.) What cost me a lot of extra time was that after every single change in settings, or trying to manually perform a match, Plastic would forcibly auto-refresh itself and spend 5 minutes scanning the changed files. (I have to keep file content detection on because Unity often overwrites files with no changes to content.) After 5 hours of struggling with this, I finally managed to think out of the box and realized I could split the moves into separate changesets. That solved the issue, but now the repository has a bunch of changesets instead of just one clean one. Taking a hint from TortoiseHg, I would suggest a way to disable automatic detection of moves, and make that a user-initiated action instead. The user should be able to open a dialog that performs move detection, and then the user should be able to fine-tune the detected moves to their liking. Only after closing that dialog would Plastic need to rescan the working directory. Also check out TortoiseHg's efficient context menu for choosing individual moves: when you right-click a file that isn't versioned, you get a context menu that lists all deleted files. Selecting one of these marks those files as a move pair. This is fast because it doesn't require any similarity matching (although I think the deleted files may be sorted by filename similarity to the right-clicked file - much faster than full content similarity checking. This would be great to have as an alternative to full content matching when Plastic is detecting moves.) Regarding the support thread, I don't think I've done that. Maybe it's a different user with a similar issue?

But I can't do that for a move that has already been detected. The "Search matches" item is greyed out for an item that Plastic has detected as moved.

Hi there, I'm dealing with a situation where there is a large number of files moved outside of Plastic SCM (Unity assets and their .meta files). For the majority of files, Plastic has detected the moves correctly. However, among the hundreds of files, a few have been detected incorrectly, such as .meta files for two assets have been swapped. How do I tell Plastic that I want it to change the move it detected to point to a different pair of files? Thanks! -- Aki

Hi Carlos, Thanks for the quick reply! I got it working now, thanks for pointing me to the correct docs. I was looking in the Administrator's Guide at https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide#Chapter16:Configurationfiles which only has a brief overview for filetypes.conf and no link to the book. Cheers, -- Aki

Also, how does filetypes.conf work? The documentation is a bit vague. I created a filetypes.conf file and placed it in the project root folder, with the following content: filetypes.conf *.asset *.cginc *.mat *.meta *.prefab *.shader *.unity But when I load up the Plastic SCM GUI, nothing has changed - those files are still treated as binary by both the "Show Diffs" option in Pending changes, as well as the Diff context menu commands. Thanks, -- Aki

Hi Carlos, OK, that makes sense, for files that are used frequently. However, for projects that have data files with many different extensions (or no extensions at all), this is a lot of maintenance work. In the case of files without extensions, you can't even determine whether a file is binary or text, if they have come from different sources. Finally, this falls apart if there are multiple sources for files with a certain extension, one of which generates text files, and the other binary files. For example, .dat is a frequenly-used extension, and depending on the software generating it, it may be text or binary. Why not have two context menu items, "Diff as binary" and "Diff as text"? This would allow the user to perform a diff quickly without any time-consuming configuration or relying on extensions. Right now, if the user has the wrong configuration, the UI effectively prevents a diff from being made. Cheers, -- Aki

Hi there! I imported a Git repo of a Unity project using fast-import. For some reason, Plastic SCM decided that all .unity, .prefab, .asset and .meta files are binary. This means I can't see quick diffs in the Pending Changes view, and I can't launch the diff viewer using Ctrl+D. All I get is an error message saying that only image formats are supported for binary files. This leads to two questions: 1. Why didn't Plastic SCM recognize these files as text? Most are normal UTF-8 encoded text files, some are ASCII. 2. How can I force a text diff on two files, even if Plastic SCM thinks they're binary? Thanks!

Ah, I figured it out! I changed from PowerShell to Command Prompt, and things started working. Git produced the export in a matter of minutes, and the file size was a little less than half of what was generated when using Powershell. I'm guessing PowerShell insisted on using UTF-8 encoding or something weird.

In case this is relevant, I'm on Windows 10.

Thanks Carlos! Still need some further assistance though. Following the example in the help page for fast-export, I exported the bare repo using the following command (took about an hour and a half): git fast-export --all -M --signed-tags=strip --tag-of-filtered-object=drop > export.dat Then I tried using this command to import it: cm fast-import PlasticRepoName ..\GitRepo.git\export.dat And received this output: ]uldn't process command [??b l o b ]ror: Couldn't process command [??b l o b

Hi there, New user here, trying to figure out how to migrate an existing Git repo into Plastic Cloud. This is just a one-time operation, I don't need to sync anything with Git after the initial import. I have a local Git repo in bare format, exported with the git clone --mirror command. How do I use this package as the basis of a new Plastic Cloud repo? Thanks in advance!