Version Control for Non-Textual Files & the Story of Blendit
![splash](/media/splash-1000w.jpeg)
For the first time, back in 2020, I had to develop my very own piece of software for the final project of David Malan's class, CS50. While searching for actual problems that I could or at least try to solve I realized, looking back at myself and my friends who did creative work, that we often wanted to save multiple versions of our work and resorted to duplicating files with filenames appended with numbers or dates .
At this point I was aware that computer scientists had faced the same problem and solved it decades ago! That made me wonder why Version Control was only prevalent within computer science.
While we did not explicitly use Git in class, every time we used CS50's internal tools to submit code, we were using both Git and GitHub. Towards the end of the class I was introduced to Git in multiple lectures by Brian Yu and to GitHub in a seminar by Veronica Nutting. I had also watched the CS50 on Twitch live stream by Colton Ogden with Kareem Zidane on the workings of Git and GitHub. All these resources rendered very useful to my project and there are definitely more from CS50 itself!
With that I figured this is because a Version Control System (VCS) like Git is designed for textual files as opposed to Blender, DaVinci Resolve, or other graphical files. This raises the question of why there is not a VCS designed for non-textual files.
Earlier that year I was introduced to Blender and had come across scripting for Blender but had not looked into it. However, I noticed that whenever you performed any action in Blender it logged the corresponding function calls in the Info window. So if I could somehow record all those function calls and executed them within a new Blender file I should be able to recreate the original Blender file! This way I could save all the function calls in a Python file and can use Git as it was intended.
However it was not that simple. For one Blender did not log all actions and I did not think I would be able to pull it off in time for class. Therefore I settled on a more approachable solution to the problem.
OneProjectFile - Version Control for Creative Professionals
![project](/media/project-1000w.jpeg)
OneProjectFile aims to bring basic version control functionality to a wide range of file types. And this is achieved by storing all the files in the user’s Google Drive.
I narrowed the scope of the problem to just focus on keeping track of all the different versions of your project without having to worry about different file names, hence the name OneProjectFile (technically Folder but we shall not talk about that).
While, yes, technically it is a VCS, it is not a good VCS as it is not efficient.
Each time you commit your project to OneProjectFile it still duplicates your project but uses the commit ID as the filename and maintains a record of all the commits. So each time you select a commit, it serves the files corresponding to that commit.
I finally graduated last month and began to realize the idea I came up with almost two years ago. I had also come up with the name, Blendit (Blender + Git), back then!
What is Blendit (Blender + Git) ?
Blendit is an Application Template for Blender (similar to an add-on) which can be installed within Blender. Blendit is a Git integration which brings Version Control to Blender.
Although Git is designed for textual files, it can track non-textual or binary files like Blender files. According to Sybren on Blender Stack Exchange, Blender Institute uses Subversion.
At the Blender Institute / Blender Animation Studio we use Subversion for our projects. It works fine for blend files, but you have to make sure they are not compressed. Compression can cause the entire file to be different when only a single byte changed, whereas in the uncompressed blend file only that one byte will differ. As a result, binary diffs will be much smaller, and your repository will be faster to work with.
How is Blendit Different?
Instead of tracking the Blender (binary) file itself, Blendit tracks the changes you make to the Blender file in real time. It does so by keeping track of the Python commands, from the Blender API, used to make changes.
This way we only track a textual (Python) file as Git was intended to be used.
Each time you open a Blendit project, it regenerates the Blender file. This means you can delete the Blender file and still retain the project.
In theory the size of the entire project should be lower than using any other VSC.
With all that said this is just a proof of concept and far from production ready. As mentioned earlier Blender does not log all actions out of the box. There are ways to make Blender log all actions, but that would add huge overhead in the system. The way I get around this is by subscribing to required events using Blender's Message Bus. However, the Message Bus is in its early stages and cannot subscribe to all types of events. See release notes to know more.
In Conclusion
If you find this interesting, check the website and download Blendit - It is Free!
Star Blendit on GitHub! This is the easiest way to show support for the project. Do report issues or provide suggestions. Contributions are welcome.
If you would like to learn Computer Science and want to build something on your own, CS50 is a great starting point - It is the best class I have ever taken! You can sign up to attend live lectures via Zoom or watch live on YouTube - today is lecture 4.