Capstone Blog Series #4: The Home Stretch

Early design for the attic level

Originally posted to blogs.oregonstate.edu on May 19, 2023

I can’t believe we’re in the 7th week already! It’s funny how things often seem so slow at the time, but looking back it feels like this quarter has somehow been shorter than the rest. I’m also definitely feeling some much needed relief now that we’ve received our grades for the midpoint archive. In today’s fourth and final post for this series I’m going to discuss a problem my group experienced and some new techniques I needed to learn to address it.

About a week and a half prior to the midpoint assignment I noticed a large number of files were either duplicated or overwritten when I merged a big update from the main branch into my development branch. My work from the week prior was missing too. After the initial few minutes of panic subsided, I started digging into previous merges to find out where things went wrong. What I found was not encouraging. Apparently an update to one of the asset packs we’re using in Unity had caused some issues when it was merged into main and I had just overwritten my branch with those changes. I notified my team and we started trying to reverse the bad merge. However, our inexperience with PlasticSCM got the better of us, and there didn’t seem to be an obvious way to fix the main branch or even save my own work. At this point I offered to do some more research before we attempted anything else that might lead to a destructive outcome. As I read through the documentation I learned a lot about this style of version control and how it differs from git, the system with which I’m most familiar. For a quick, high-level, overview I recommend “The World According to PlasticSCM” from the introduction guide. First of all, PlasticSCM tracks files as well as directories via an ID. This was huge, where my team and I were used to versioning only files, PlasticSCM was treating every new directory, including its contents, as unique. No wonder a big update had caused an even bigger problem! Second, PlasticSCM treats repositories like containers rather than pointers. What does that mean? Well as The World According to PlasticSCM notes, “any changeset can fully reproduce the structure of the workspace at the time it was created.” Ah-ha! So all was not lost, somewhere back in the main branch there must be a changeset that completely represents that state of our project before everything went wrong.

Now that I understood how we get to the current state, I had a much better idea of how to undo it. From here I created a plan to set us back on track using subtractive merges, then very carefully merging the updated assets back in making sure to handle conflicts the PlasticSCM way. In the end I was able to save everything except for the work that I hadn’t checked-in before I blindly pulled the updates into my branch. It was a hard way to learn the differences between PlasticSCM and git, but I’m glad none of my teammates’ work was lost in the process. I shared what I had learned with the group, and I’m happy to report that we haven’t had any more problems. Looking ahead, I’m excited to continue work on the project and I’m more confident than ever in our ability to work together as a team.