They use subversion, we use git

O’Reilly Media’s DocBook build system lives in a subversion repository, and that’s just fine, but we like to use git. Subversion is more than adequate for a book. We’re not really dealing in code, and we don’t really branch a book chapter. There’s already a lot of social control built into the process. One author says “I want to work on regexes” and another says “I want to work on subroutines” and off they go to work on those separate chapters. Since the outline is mostly set in stone (but one of those really soft ones, not like Bedrock), we don’t have to move a lot of files around or guess at cross references. This means that we don’t need excellent branching and merging support.

We do, however, like the other distributive features of git. Randal and I travel quite a bit, and we don’t want to wait until the plane lands to make a huge commit that covers all the changes we made to a file over the last several hours. Small commits are the way to go. We finish a small task and we commit. We don’t have to remember what we did (or why) because we don’t wait to write the commit message.

Git gives us an interface to subversion. Don’t ask us how it works, because it just does. Someone in the tools group at O’Reilly gives us a URL for our book’s subversion repository. We clone that in git:

$ git svn clone https://prod.oreilly.com/external/authors/books/...ISBN.../current

Now we have it all in git. That takes awhile because we had to go through the entire repository to let git create the history that we wanted. That’s no big whoop though.

We write and write and commit and write and commit as much as we like, doing all of the normal git stuff that we like to do. When we are ready to send it back toward O’Reilly, we use the dcommit

$ git svn dcommit

And, everyone’s happy.