DEV Community: Max Pixel

Extrinsic Role Headers: Standardizing Member Order for Faster and Deeper Comprehension

Max Pixel — Sat, 30 Dec 2023 22:45:10 +0000

Moved to https://m-pixel.com/extrinsic-role-headers-standardizing-member-order-for-faster-and-deeper-comprehension/

UE5 Anti-Practice: Collision Components Under a Mesh Component

Max Pixel — Sun, 09 Oct 2022 00:00:04 +0000

Moved to https://m-pixel.com/ue5-anti-practice-collision-components-under-a-mesh-component/

Prefer auto* Over auto for Pointer Declarations in C++

Max Pixel — Mon, 05 Sep 2022 23:10:27 +0000

Moved to https://m-pixel.com/prefer-auto-over-auto-for-pointer-declarations-in-c/

How to use Plastic SCM's merge tool with P4V

Max Pixel — Mon, 05 Sep 2022 20:58:03 +0000

Moved to https://m-pixel.com/how-to-use-plastic-scms-merge-tool-with-p4v/

pwsh saved me from unix

Max Pixel — Sun, 07 Feb 2021 00:02:08 +0000

PS /home/max> rm ./DuetSoftwareFramework/
/usr/bin/rm: cannot remove './DuetSoftwareFramework/': Is a directory
PS /home/max> rmdir ./DuetSoftwareFramework/
/usr/bin/rmdir: failed to remove './DuetSoftwareFramework/': Not a directory

Thankfully, I have a competent modern shell to save me from this archaic nonsense.

PS /home/max> Remove-Item ./DuetSoftwareFramework/

Remove-Item succeeded where both rm and rmdir failed. And for reference, ri is an alias for Remove-Item.

Sudo in Windows 10

Max Pixel — Fri, 14 Aug 2020 05:31:25 +0000

ssh max@localhost

It's longer than sudo, but it's shorter than Start-Process Powershell -Verb runAs (and doesn't open a new window).

But, Max, that's just an SSH login command!

That it is! Windows 10 has built-in OpenSSH now, both server and client. It just so happens that the Windows 10 SSH server gives administrative users an administrative context. It's understandable why they would do it that way, given that Windows doesn't have a sudo equivalent, and that SSH is often used for remote administration.

So, whenever I need to bash out a Chocolatey command, or... is there anything else I ever need an administrative console for? Anyways, whenever I need to do that, instead of opening a new Windows Terminal window, I just ssh max@localhost my way to super-user success!

Exploring Two-Way Sync Between SVN and Plastic SCM

Max Pixel — Wed, 13 May 2020 06:40:19 +0000

I'm often asked by customers to do work on some project that is being tracked in SVN. Having been spoiled by Plastic SCM's very well-thought-out system, SVN's crufty paradigm soup of fragility and slowness is mind-numbingly infuriating. I looked into what I could do to work with Plastic on my end without any inconvenience or interruption to the customer (that is to say, without creating any additional inconvenience or interruption beyond that which is already imposed upon them by SVN).

The simplest approach is, of course, to point an SVN client and a Plastic client to the same workspace folder, managing back-and-forth manually: Pull latest in SVN, commit in Plastic; merge to main in Plastic, commit in SVN. I thought it would be worth exploring the possibility of a solution that would actually maintain the entire history of the SVN repository in Plastic, so that I can see annotate history in my IDE, see incremental Blueprint change diffs in Unreal Engine, etc. Really, so that I can use it as proper and fully-featured version control rather than just a file transfer mechanism with an undo feature.

I quickly found Plastic's guest blog post about migrating from SVN using git-svn and then Git Sync (Git Sync being Plastic's built-in feature to synchronize between Plastic and Git). I started following the steps in the post, but found that git svn was a bit too cumbersome - there were a lot of things that left me thinking, "this could really use a script to simplify the process and improve the default behavior". I figured, if I was thinking that, then somebody has probably already thought the same thing and created those scripts.

I found svn2git (in particular, this implementation of svn2git in a Docker container with a nice config file and automatic recurring sync). How about that? Not only had somebody already written the scripts, but they happen to be my crazy internet doppleganger. I didn't even know I had one! Touche, Crazy Max, touche.

After making several fixes to Crazy's setup, and modifying it to use git:// instead of ssh://, I have SVN to Git to Plastic working very well. The svn2git container is configured to push each repo to a git daemon container (eventually I would like to figure out how to avoid this data redundancy - to have the git daemon use the same .git folders as svn2git - but currently one seems to require bare while the other requires working copy). I then use Git Sync from the Plastic GUI (I plan to automate this at an interval, too).

I realized that I could ditch the git daemon, and instead use Plastic GitServer, configuring svn2git to push directly to that, instead. Having read that Plastic Git Server maintains two copies of the data (Git format and Jet format, I assume), I decided to stick with the git daemon middleman in favor leaving open the possibility of consolidating the git daemon and git svn "databases" (I doubt I can have git svn and Plastic GitSync use the same .git files as easily).

Once I had this working, the next step was to figure out how I would get data going back in the other direction. My team prefers branch-per-task, but most SVN-using customers tend to prefer big commits to trunk as the default mode of operation. Again, there is a very "straightforward" solution: I can point SVN to the same workspace and commit to it while Plastic is on the feature branch; but even if the customer doesn't care about task branches and granular commits, wouldn't it be much better if I could see those merges in Plastic? Especially so with Plastic GUI's feature to show merged vs unmerged branches as different colors in the graph view.

So, let's say that I merge our task branch into /main, sync that to master in the intermediate Git repo, pull it into the git svn working copy, and then finally dcommit it to SVN. Given that Git Sync syncs everything without any ability to filter branches, I must expect that my task-branches and merge-commits will be synced as such into Git. This is an unfortunate waste of hard disk space, but it's not a dealbreaker as long as the Git-to-SVN push treats the merge-commit as a regular one. After reading about git svn dcommit's behavior when merges are present, it appears that this is exactly how git svn behaves by default - yay! However, this action will replace the original merge-commit with a new one. My past experience tells me that replacing commits in Git causes Plastic to fail subsequent Git Sync operations unless the conflicting changeset is removed from Plastic. I was still willing to give it a shot, however...

At some point in the past, some error message that I got from Plastic brought to my attention the existence of %LOCALAPPDATA%\plastic4\sync\git. I poked around in there and found that cset.mapping.conf contains very straightforward association between Plastic changesets and Git commits. I figured I could potentially work around any issues by replacing the mege-commit git-hash with the svn-rebase git-hash in this file.

To my surprise, however, I didn't end up needing to touch those hidden files. When I ran a Git Sync after everything else, Plastic brought the replacement merge commit in alongside the existing one. The resulting forked head prevented it from pushing the first merge-commit back again. I was surprised again to see that the replacement commit appeared with an identical merge link! I didn't expect this having read that git svn dcommit destroys merge links, but it seems that the Git community has fixed that shortcoming. At that point, all I had to do was to delete the original merge-commit, leaving the replacement one.

I'm left with a working bi-directional system. It will require a bit of additional automation before I'm totally satisfied with it, but it's already sufficient to begin saving myself and my team some time and agony.

Moving a Docker Volume to a different Windows computer

Max Pixel — Fri, 10 Apr 2020 02:07:16 +0000

Today, I needed to transfer my Postgresql instance from my laptop to my always-on machine. The database and accompanying application are in the early stages of development, so I haven't set up any sort of replication or backup yet. In fact, after discovering how undesirably complex and inflexible this is for Postgresql, I intend to switch to Cassandra. I'm not going to port my API to Cassandra in just a few hours, though, I need to use it today, and transferring it seems a small enough task that I should just get it out of the way now.

The codebase is already replicated to all of my machines through Plastic SCM, however the actual data of the database lives only on my laptop. I have Postgresql's persistent data set up to be stored in a named volume. According to Docker's documentation, the correct way to back up and restore named and anonymous volumes is to copy the files from named-volume to host-volume using a temporary container that binds to both and runs a cp, tar, or similar command to copy the data from mount to mount.

The example given in Docker's documentation, however, assumes that Linux containers are being used. In my case, I'm running Postgresql in a Windows Container. These are the commands that I ended up running (in PowerShell) to get it to work:

mkdir backup
docker run --rm --volumes-from masterbrain_postgresql_1 -v $PWD/backup:C:/backup mcr.microsoft.com/powershell:nanoserver pwsh -Command cp pgsql/data/* backup -Recurse

There are a few caveats that required a few unintuitive elements that I had to include in the command:

The local backup folder must exist before I can run the docker command - if it doesn't exist, Docker will return an error instead of assuming that I would like it to mkdir for me.
Docker for Windows does not accept relative paths in bind-mount specifications - prefixing the relative path with $PWD satisfies this requirement.
Docker for Windows also requires the use of drive letters. Even though / is sufficient in pwsh, scp, and many others, docker requires C:/.
The official powershell image does not set pwsh as the entrypoint - when specifying a command in the docker run line instead of entering an interactive session, in order for that command to actually run in PowerShell (the whole point of using this image), it must be prefixed with pwsh -Command.

Once I had everything copied into the backup folder, I needed to transfer those files to the other computer. I already have all of my machines set up to ssh into each other (I find this a bit more convenient than setting up ActiveDirectory for a company of two), so I chose to do so using scp. You can use any other method, though, such as SMB or a flash drive.

ssh max@alwayson mkdir /temp/pg
scp -r backup/* max@alwayson:/temp/pg

Just like with the backup, I'm required to create the destination folder first. If I don't, scp fails with the shockingly uninformative and misleading error message, "lost connection". rsync could accomplish the same thing in just one command, but the Windows version of rsync is still awful.

Now that the database files exist on the target machine, the last step is mostly the same as the first step with the directories reversed:

docker-compose up # followed by a ctrl+c to close it as soon as it's up and running
docker run --rm --volumes-from masterbrain_postgresql_1 -v C:/temp/pg:C:/backup mcr.microsoft.com/powershell:nanoserver pwsh -Command 'rm pgsql/data/* -Recurse; cp backup/* pgsql/data -Recurse'

This time, I didn't need to create any folders beforehand, but I did need to create the named volume. I accomplished this by spinning up my composition, which also allows me to use the same --volumes-from approach. I also had to add an rm to make sure that the resulting named volume didn't contain anything not in the backup folder. Note that in order to run two commands (rm and cp) inside of the container (instead of running one inside and one outside), the commands need to be encapsulated in quotes.

In retrospect, there appears to be a slightly more straightforward solution: An scp-equipped container on my laptop could scp the files directly from its named volume, directly into a named volume on the target machine, if there is a container running on the target machine which is bound to the named volume and is configured to accept SSH connections from the container on my laptop. That said, while this approach would reduce the number of "hops" that the data goes through, it's much easier to remember and bash out the above commands than it is to get two containers talking to each other over SSH.

FastestBinaryStream

Max Pixel — Mon, 17 Jun 2019 05:59:47 +0000

Moved to https://m-pixel.com/fastest-binary-stream/

Deconstructing OnlyKey Agent

Max Pixel — Tue, 04 Jun 2019 17:08:55 +0000

Moved to https://m-pixel.com/deconstructing-onlykey-agent/