Blender coding: version control

Workflow Introduction

Recently there was a call for Blender development videos to help new developers find their way into Blender development. I think this is a good idea, and I might participate with videos at some point. For many purposes though, text is an easier way to convey this kind of workflow information. This is the first in what might be a series of posts describing some of my own development style. The information in this post is not necessarily very in-depth; you’ll want to make good use of Google if you aren’t familiar with some of the underlying concepts. That said, feel free to ask any questions in the comments.

One good thing to remember: every developer has their own set of preferred tools. I’ll focus on the tools that I use, but it doesn’t mean my way is the only way or the best way.

Git and SVN

For this post, I’ll talk about getting the source code in a convenient format. Blender uses SVN for source control, but a lot of developers are locally using git instead. There are multiple ways to do this; there are existing git clones on both github and gitorious that you can clone from. Personally though, I find it best to use git-svn so that I can easily update directly from trunk (as well as commit to it.)

Ordinarily with git, you get the entire history of the project going back to the initial commit. Unfortunately, because SVN was not designed with this capability in mind, git-svn has to get each SVN revision separately, which can take a very long time. For this reason, I recommend starting your git clone of the repository from a relatively recent SVN revision. One way to find recent revisions is to check the bf-blender-cvs mailing list archives. From there, choose the [ Date ] link for the latest month. The latest commits will be at the bottom of the page, with the revision number in square brackets. For example, this commit from March 2012 is revision 45296.

Incidentally, if you’re really interested in Blender development, whether as a user or a developer, I recommend subscribing to the list. You can then pretty easily follow along with Blender development as each bug fix, code cleanup, and feature commit shows up in your inbox.

Downloading Blender’s Source Code

Once you have selected a recent revision, you can create your git clone of the repository with this command:

$ git svn clone -r 45296 https://svn.blender.org/svnroot/bf-blender/trunk/blender
  • Replace “45296” with whatever SVN revision you have selected.
  • This will get you SVN’s trunk but no other branches. If you do want other branches, I’d recommend cloning them separately, otherwise you have to mess too much with git-svn.
  • This does not check out the lib directory. I’ve never used the lib directory, but my understanding is that it’s huge and a pain to work with.

Running the command will take a while; you’ll see it initialize an empty repository and then slowly download and add all the files (a bunch of lines starting with ‘A’ followed by a path.) Once this finishes you’ll get a new directory called blender in your current directory containing all the code. (It’s completely safe to move or copy this directory to another location; git won’t mind.)

At this point you can change into the new directory and run the git log command to see what you’ve got:

$ cd blender/
$ git log
commit c72ea3024bed1148d03d65af70081e9781f03dad
Author: nicholasbishop <[email protected]>
Date: Fri Mar 30 17:30:24 2012 +0000

   Add BMO function to append to a buffer slot.

   git-svn-id: https:[email protected] 954f8c5b-7b00-dc11-b283-0030488c597c

That’s the full history we have right now, one single commit. Note that last line; for any commit that is in SVN (as opposed to something you’ve done locally on your machine) you can see its revision number after the @ sign.

Downloading Fresh Updates

Assuming the SVN revision you selected wasn’t the very most recent, you should now update the repository using the rebase command:

$ git svn rebase
	M	source/blender/bmesh/intern/bmesh_marking.c
	...
	M	source/blender/editors/mesh/editmesh_tools.c
r45297 = b86ee181d1a821a12435585b807259df1c7d672b (refs/remotes/git-svn)
	M	source/blender/modifiers/intern/MOD_array.c
r45298 = 950d5b00f7b60e9c179797af5e8a29500bd742a0 (refs/remotes/git-svn)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/git-svn.

If you re-run git log, you should now see all the latest commits from SVN. For brevity, you can show just the first line of each log message:

$ git log --oneline
950d5b0 Fix bug 30195, Array modifier fails to merge vertices.
b86ee18 For BMesh functions that test flags, add enabled/disabled variants.
c72ea30 Add BMO function to append to a buffer slot.

From now on, you can use the git svn rebase command any time you want to get the latest changes from SVN.

What’s Next

The commands above are pretty passive; you can get the code, view log history, and pull updates, but of course there’s more to it. I’ll discuss some of my specific usage in an upcoming post, but for general git information I highly recommend the Pro Git book, available for free online. The git man pages are also useful for learning about specific flags, but they can be a bit of a tough read without prior knowledge of commands.

That’s all for now. I expect I’ll be writing more about git soon, and (as I find time) other topics like compiling, searching, and editing the source code in Emacs. As noted earlier, please feel free to ask questions below.

8 thoughts on “Blender coding: version control”

  1. Thanks for spending the time to write this, I’ve tried a gitorious clone but always manage to run into various not-very-common situations with GIT, which are hard to work through even with extensive googe’ling and reading up on docs :S

    I’ve used GIT outside of blender and found it works well so Im guessing these are complications from git/svn conversions but not sure :/

    Using git-svn looks more straightforward, I’ll be sure to look into this :)

  2. Heh, the ‘fullblender’ on gitorious took something like a month to do a full clone from svn with all the branches, lib dir and full history…but it does have all the branches (git style) and lib directory if someone’s into that sort of thing.

  3. hi
    can you explain how to get a diff with the current blender code?
    i mean using: master…pose_sculpt > test.patch
    will export all the commits including the blender pushes from the svn, which are already present in the repo. i want to merge the changes with!

    what i want to do simple export the changes from the code to patch it in my builds, what i do now to accomplish this is by using master…pose ,it will export all the commits. then i filter them but searching if the file includes the commiter name ie. “nicholasbishop”, then i further filter by comparing if any of the commits matches the ones in the svn.
    and that’s is a headache for sure!, if it is possible to minimize this effort, help me, thanks in advance :)

    1. I’m not 100% sure I followed the question; if you are trying to get a diff against trunk from a clone of my github repository, then something like “git checkout skin-modifier && git svn diff trunk > foo.patch” should do the trick. On the other hand, if you want to get a diff against trunk from your own git-svn repository, try this script: https://gist.github.com/833214

    2. You should look into “git cherry” I think. It gives you all the commits that are in master but not in your branch (or the same between any pair of branches), by comparing the patches, thus handling the different commit messages and such that can arise from git-svn. git log master..branch will only filter the commits that are exactly the same, up to the SHA-1. Also, think about the –author and –grep options to git log

  4. | For many purposes though, text is an easier way to convey this
    | kind of workflow information.

    To convey but to FOLLOW! thank you 1000x.

    Nowdays, people are doing videos only to “expose themselves” and to impress the noob.

    Video can be a support for a text, not the main source.

Leave a Reply

Your email address will not be published. Required fields are marked *