I’m switching to a slightly different git workflow for my dynamic-topology branch: instead of force-pushing rebased updates to a single dyntopo branch, each push that involves a rebase will go into a new branch with a numbered suffix.

If you are building dyntopo, you won’t need to do the “git checkout trunk && git branch -D dyntopo-slim && git pull && git checkout dyntopo-slim” dance anymore. Instead you can just do “git fetch” followed by “git checkout dyntopo-N“, where N is whatever the latest branch is. Currently the latest branch is dyntopo-2, but I rebase frequently with dyntopo so that will change.

Update: for people who were having trouble building, it looks like there was a build problem in trunk with OSL disabled. The dyntopo-6 branch has latest trunk which should fix that issue.

A common question I’ve seen is “why isn’t dyntopo in trunk”? Sometimes it’s phrased more as a statement: “dyntopo is no more unstable than some other features in trunk, so it’s time to commit it!”

I want to reassure folks right now: there’s no secret cabal keeping dyntopo out of trunk. It hasn’t been code reviewed and found wanting. Rather, I don’t want it in trunk yet. As the owner of the code, it will be my responsibility to maintain the code more or less forever. I need to handle any bugs the code creates. I need to make sure the code is comprehensible for other developers. And in order for sculpt development to continue, I need to ensure that new features don’t make the code harder to develop further.

There is code I wrote years ago for Blender that still causes me (and other developers) headaches. I try to reduce the chances of that happening again by doing very careful review of my own work, writing documentation, getting user feedback, getting the code reviewed by another dev like Sergey or Brecht, and only then committing it.

I want to be clear that I don’t mind people asking the question “why is dyntopo not in trunk?”. Most people fully understand that I have a job and limited time for doing Blender work, and are asking an honest question about the process. Hopefully this post clears up any confusion.

It’s interesting to reflect on how long it takes some features to go from the idea stage to being a finished feature you can use in released software. It has been frequently noted that building software is not like building bridges. You often don’t know upfront what the implementation will look like, or what unexpected issues will derail the project, or what nasty bugs will appear that take a long time to work around.

In between the idea stage and the complete stage you often have an intermediate step: a test or preview of the feature where you can see it doing whatever cool thing it does. In my experience, that intermediate step usually sits much closer to the idea stage than the completion stage. I think that this is often confusing for users of the software though; they saw a video of the feature “working”, so why didn’t that feature go into the next release? Sometimes years go by and the feature is still not released. What the user doesn’t often see is the work that goes into making a feature stable and making the code maintainable.

To make maintainable code requires writing code that fits nicely with the existing software’s architecture. If that architecture can’t accommodate the new feature nicely, it’s best to make intermediate changes the build up groundwork needed for the new feature. Incidentally, this is one thing I find very helpful about my rebasing workflow in git. You might notice that the first few commits I make for larger features such as sculpt masking are often code cleanups and other non-sculpt-related changes.

Many of the features that I’ve worked on for Blender have gone through a number of re-implementations. For example, I first coded sculpt masking while working on SharpConstruct. I think I tried at least once or twice to implement masking in Blender 2.4x. I later rewrote it for Blender 2.5 during one of my GSoC projects, but I didn’t feel that code was quite good enough to go into trunk — it just didn’t have that feeling of being “obviously correct”. So I rewrote it again this year, and this time the code felt right. Even that final rewrite took months though. There is a huge benefit to getting the code right, and that’s fewer bugs to deal with. I think only a few bugs have been reported about sculpt masking so far, and all were pretty simple fixes (knock on wood.)

I include that example because after every GSoC, there’s inevitably a certain amount of disappointment from users about “failed” projects. Some express derision for GSoC as a whole, noting that so many projects never seem to make it into trunk. While it’s true that some projects really do completely fail (student disappears, or simply doesn’t have the necessary coding chops), I think it’s good to give them the benefit of the doubt. They might yet figure out how to make the project work. Even if not, they’ve probably learned a lot about Blender’s code and might contribute other features if they see the Blender community as a welcoming and forgiving environment. And indeed, I think that Blender’s users are overall nice about delays and flaws in the development process, so thanks for that :)

This has gotten a bit too long and rambly! So: next up I’ll discuss a bit more the state of SPR and some other features that are in that nebulous gap between idea and completion.

As mentioned here frequently, I have been using git-svn and a public repository on Github for Blender development. That Github repository has a couple limitations though: the history only goes back to January 2011 (which was when I first created the git-svn clone), and the commit author information is incorrect. The latter problem is due to the difference between the way SVN and Git store author data; in SVN it’s a plain username (e.g. “nicholasbishop” is my Blender committer username.) Git on the other hand typically uses a full name and email address. By default git-svn imports the username and makes up the email address (here’s an example from JesterKing’s repository on Gitorious.)

Fortunately, git-svn does provide a way to map from svn committers to git committers in the form of an authors file. Probably you could use clever git commands to edit the existing Gitorious clone and fix commit author data, but since I am lazy I just re-cloned Blender’s trunk last night with my own authors mapping file.

I renamed my github “blender-bishop” repository to just “blender” since this is now a proper clone. To download it, run “git clone [email protected]:nicholasbishop/blender.git”.

After cloning it, you can let git-svn take over with a few commands. (These are adapted from these excellent git notes on the Blender wiki.)

git svn init https://svn.blender.org/svnroot/bf-blender/trunk/blender
git config svn-remote.svn.fetch :refs/remotes/origin/trunk
git config svn.authorsfile /path/to/authorsfile
git svn rebase

After running those commands, you can still pull updates from the Github repository:

git pull --rebase
git svn rebase

I’ve only just finished making these changes, so there may yet be some bugs to work out. I also haven’t set up any automatic updating of the Github repository, so it will probably lag behind SVN trunk sometimes (although as noted above, you can update your local copy regardless.)

Update: Automatic updates are now enabled, but nothing has been committed to trunk tonight, so not verified that updates are working yet.

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.

Continue reading Blender coding: version control

Wrote a little debugging function earlier that I’m sure will come in handy again:

As posted here a week ago, I am now using github to publish my work-in-progress code. Currently there are two branches of interest there: sculpt masking and the skin modifier. When I make larger changes (such as the recent skin-modifier work) I usually post here, but I am actually updating the branches fairly frequently at this point, at minimum pulling in the latest updates from trunk, as well as bugfixes. So if you are interested in making experimental builds, no need to wait for a post here, just watch the blender-bishop repository on github.

I’ve just pushed some updates to the masking branch (fixing an undo crash and increasing the mask brush strength.) I also want to point out the nice new mask brush icon contributed by Julio Iglesias.