As you all know, there is a compression option when saving blend files in Blender.

I tested to commit the changes to GIT with a blend file consisting of 50 torus with 3 subdivisions applied. I thought uncompressed files would be much more efficient when using GIT, but regardless of whether they were compressed or not, the growth rate of the git folder was similar.
I don't understand this result very well.

I want to hear your experiences. Do you want to compress blend files when using GIT? Or would you like to uncompress?

After reading @HikariTW's answer, I carried out a more precise test. As a result, I realized that I had been mistaken. GIT wasn't just picking and saving changes to the blend file, it was just storing copies of the blend file every time it made the version. Blend files are treated as binary files, so it's natural. However, because GIT compresses and stores copies of the blend file, the size did not double. Because I didn't know that GIT was compressing when I created the version, I was mistaken for GIT to pick up only the changes in the blend file and store them in the version.

As a result, I recommend using a compressed blend file as @HikariTW said. When you commit a uncompressed 100MB blend file, GIT compresses it, makes it 33MB, and adds it to the .git folder. But if you compress and store a 100MB uncompressed file in the blender, it becomes a 33MB blend file, which is committed by GIT to compress it one more time, make it 27MB, and add it to the .git folder, so you can keep the storage smaller.

  • 1
    $\begingroup$ And what if you just use Blender build in my_donuts.blend.001 logging style save feature and ignore those file in your gitignore? Wouldn't that be more reliable without increasing the size of repo? $\endgroup$ – HikariTW Aug 12 '20 at 8:15
  • 1
    $\begingroup$ I still don't get it. Why you use GIT (that GIT) on a binary file like .blend file? There should be bunch of articles tell you Never commit binary data into GIT. with thousand of reason. Could you explain why you need a distributed version-control system with your project? If you want only back-up, using any cloud drive with auto-upload would be a better option $\endgroup$ – HikariTW Aug 12 '20 at 8:25
  • 1
    $\begingroup$ Or you can check out binary diff to make different only commit to GIT (still not a good idea). Since I don't think .blend file will be stable enough to make GIT repo small. $\endgroup$ – HikariTW Aug 12 '20 at 8:30
  • 1
    $\begingroup$ stackoverflow.com/questions/540535/…, superuser.com/questions/715690/… $\endgroup$ – HikariTW Aug 12 '20 at 8:40
  • 1
    $\begingroup$ GIT is a version control system, Source Tree is a GUI interface using GIT. GIT is not the only version control system, GitHub is a website like dropbox with GIT control system. You can search binary file or project file with GIT keyword, there should be a lot of version control system based on GIT and make .blend file controllable without saving every single committed .blend file. $\endgroup$ – HikariTW Aug 12 '20 at 8:52

Back to your title's question:

Compress vs Uncompress file into version control system?

Use compressed if the system can not create a differential

Most version control systems have their own compress algorithm when storing each file. Using Blender's compression will only confuse the system on file content and unable to find a minimum diff between different versions of files which may lead to massive amount of savings in your repository.

While some systems using .gz or other common compression methods, .blend files are most likely treated as binary files unless there is a toolchain to let the system decode the meaning of Blender's files. So an uncompressed .blend might be treated as a compressed one, then choose the smaller one since Blender's compression is specifically to it's own file type.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.