Advertisement

You're blocking ads, which pay for BlenderNation. Read about other ways to support us.

Version control isn't just for programmers

10

Jason van Gumster explains the benefits of version control systems to artists and gives a quick introduction to Mercurial.

Working with other artists and creatives, I'm constantly amazed—and, to be frank, a little horrified—when I look at their project directories. So frequently, they're riddled with files that start with the same name, but with numbered with suffices like -v1, -v2, -v3-FINAL, -v3-FINAL3, v3-FINAL3-real, -v3-FINAL5-pleasewilliteverend, and so on.

And even more amazing, often these are artists are involved in collaborative projects where more than one person may touch the same file (or set of files), often over a long period of time. I would often ask these artists, "Have you ever thought about using any kind of version control for your projects?"

Invariably, I get the response, "What's version control?"

About the Author

Avatar image for Bart Veldhuizen
Bart Veldhuizen

I have a LONG history with Blender - I wrote some of the earliest Blender tutorials, worked for Not a Number and helped run the crowdfunding campaign that open sourced Blender (the first one on the internet!). I founded BlenderNation in 2006 and have been editing it every single day since then ;-) I also run the Blender Artists forum and I'm Head of Community at Sketchfab.

10 Comments

  1. It was interesting until the point that a 'command line' was recommended. When your whole working environment is GUI based and you have no experience of any command line working, then expecting people to enter a strange and unhelpful world, just to do something that is easily done in a GUI is unlikely to be well accepted. Sure versioning is important. But I think a lack of understanding of user behaviour, especially artistic users, let's it down.

    • "And while most of the other DVCS programs have ports with command line interfaces, Mercurial has a very mature graphical front end in TortoiseHg".

        • A lot of folks simply prefer the command line as a quicker way of doing the same task. Some also advocate teaching the command line before the GUI to educate the user on the 'under the hood' aspects of the software they use. It's likely a little of both, here.

          • That applies to people who are used to using a command line, and often combine it eith other keyboard and text based tasks. The article author included. For normal users, and especially users of graphical software, they will never go near a command line ever. There is never the need. And learnability is very bad. You will need a lot of support to get started and copious notes or an excellent memory if you ever want to go back there. And for what benefit? If the GUI is good there is no need. It's not by chance that nearly everyone today uses a GUI for everything. And outside of IT nobody. If you work in usability, there is no question about it. The CLI is a legacy niche that will die out despite what a tiny number of diehards might say.

        • Hi there!

          I'm the guy that wrote the article. TortoiseHg (the GUI recommended in the article) is fantastic. A lot of the artists I've worked with only use that. The thing is that often GUIs (in general) present you with way more functionality than you need to know when you start using the tool. In my experience, it's much easier (and better in the long run) to learn a new concept with as few distractions as possible. For example, it's much easier to explain what a commit is in natural language than it is to do that *as well as* teach where and when to push whichever button corresponds to that concept.

          It's also worth noting (particularly with the resurgence of voice commands) that there's a renewed interest from the interface design community in text-based interfaces. With that kind of attention some of the continuing advancements in natural language processing, it's interesting to see where those interfaces may go in the future.

          And, as I said in the article, this is what works *for me* and quite a few people (yes, artists) I've worked with. Some other system may work better for you... but any sort of version control is better than none.

  2. I use Hg mainly for code and sometimes for a binary file. Since Hg and many other version control systems store the diff between version for text file, what is the experience with large binary file? Is it noticeable in performance?

  3. Id love to see a visual version control addon for blender. Save snapshots, with visual screenshots associated with each, along with comments.
    Command line version control has no place in the visual arts, I've tried for years.

Leave A Reply

To add a profile picture to your message, register your email address with Gravatar.com. To protect your email address, create an account on BlenderNation and log in when posting a message.

Advertisement

×