# Version control for .blend files

I know this question has been asked before, but maybe things have changed?

I'm thinking of starting to use version control on Blender animation projects (especially because we are starting to do VR stories as well as traditional films). Having a good GUI is one of the most important things for us, so that I can get all the artists to use it (artists don't like command lines). Git seems to have the nicer GUIs available, however people say it doesn't handle large binaries very well (though some people say it handles .blends very well). The other options I've seen are SVN and Mercurial.

Has anybody used these version control options for an animation pipeline? Which one is best suited for a small studio? Why would I choose one over the other?

• Is this about blender or something else?
– user1853
May 8, 2018 at 22:37
• It's about version control, but in regards to blender projects May 9, 2018 at 18:17
• We are a small developer studio and use Perforce for pure-binary projects. But it has its hiccups. I have found Snowtrack and Alienbrain. I haven't tried either of them, but they both look interesting. Jul 22 at 12:30

Afaik, .blend files are binary files which contains a database; so version control for binary files is what you're looking for. Tipically this is adressed by Perforce, which seems to be the solution to go for medium size to heavy weight needs. Alternatively, git-lfs can be good for large files too. Regarding using standard git, I cannot tell for sure as I never used to save binaries til now. If you use decide to use git, you'll find a host of clients guis for it. Personally I stick with Atlassian SourceTree, which has support for git-lfs too. But this is just my inclination.

EDIT: As pointed by dr. Sybren, there's Subversion, which considerably has the advantage over Perforce of being free, while being in the same class.

EDIT2: There's PlasticSCM too with this Gluon gui tool and Unity plugin, if you really need an artist-simplified scm workflow.

• Un-upvoted. Your edits introducing wrong/misleading information. May 14, 2018 at 9:46
• what is the misleading info? It seems to me I only added more of the same...
– Kabu
May 14, 2018 at 10:28

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.

This may be of use.

There is also in the Preferences -> File -> "number of Save Versions", for a default tool.

• Looks like good tools! Unfortunately, I need something that will work with .blend and lots of other files like .psd May 9, 2018 at 19:52

Version control software (VCS) can be grouped into two categories, client-server and distributed. You can find a list of open source and proprietry VCS here.

A distributed VCS generally stores a complete copy of the repository on every client machine. While this does have advantages, for large repositories that are common with animation projects this can be a big drawback. While you may have 10GB of data files, you get 100's of GB or even TB of history data, when you start a new machine working on the project, that entire history needs to be copied to the client, this can take a long time and use a lot of extra storage. To avoid this, git, for example, allows you to store only parts of the history. However, with git you need to maintain the local history manually from time to time.

In contrast, a client-server VCS only needs the full history on the server with each client holding two copies of the current version, one is a clean copy that can be compared to the working file to decide what changes need to be committed back to the server. So when you have 10GB of project files, you only need to copy 10GB of data across to a new client machine, which can then be duplicated locally into working files, you can also checkout only a portion of a project to reduce this if you don't need all of the project files for the task.

When it comes to open source, there are several distributed VCS options but subversion is the only choice for client-server VCS. There are several clients available for subversion, most of which are listed here, while many are web based for viewing the repository or developer tool integrations, there are several standalone GUI's as well as desktop integration options that add svn commands to your existing file browser.

• Oh, this is really interesting. Makes me wonder if we should be going the SVN route, when before I was leaning towards git. Our biggest project (not including image sequences) is 485Gb, would that grow to a ridiculous size with git?Currently our version control is just save and increment files, so we have tons of extra files we don't need, and the project folder is very messy. Would git-lfs get too bloated as well? Is there no way to clean out commits before a certain date to save space in the repo? May 10, 2018 at 15:40
• @EricEDFilms every commit made adds to the history, the more a single file is changed and committed the bigger the history. Keeping the history is the point of using VCS, so the only way to get rid of it is to start a new repo with the current files. As dr.sybren mentions, compressed blend files make larger histories. With uncompressed blends, the diffs saved for a binary revision should stay smaller than saving a full copy of each file. The biggest plus for using VCS is that every user can quickly check they have the newest files and are sharing all the work they have done. May 10, 2018 at 18:03
• Note that although git is a distributed VCS, you do have the --depth option when cloning, which will limit the local version history to that number of previous versions. See documentation for git-clone. As your project progresses though, you will accumulate more and more history, which could necessitate periodically re-cloning if the local repo gets too large. Nov 26, 2020 at 1:12
• @MichaelDorst you don't have to reclone to free up disk space
– Dean
Jul 18 at 4:02