Anthony Panozzo's Blog

I recently had a chance to use the Git interface to Subversion (git-svn), and it's the best way that I've found to work with Subversion (SVN). Using git-svn is better than using plain SVN. The primary reasons I feel this way are that it provides a convenient staging environment and superior local branching capabilities.

The staging environment provided by Git means that I have a local version control system that no one else can see. This allows me to take continually check things in without worrying about mucking up the general repository. I like this because I can make changes quickly and check in whenever I make progress and things mostly run correctly. This is great because I hate it when things are improving and then I make some boneheaded change to a bunch of files and can't figure out how to get back to a working state.

When I'm ready to check into the shared repository (in SVN), I can do this as a separate operation. What's nice is that I can squash, modify, and reorder local commits so that my development history is clean of the rabbit trails that inevitably pop up. Theoretically, the staging environment allows me to not need to run full test suites before locally committing to ensure that I don't break the build. This was not really a gain that I utilized though.

The second advantage was quick local branching capability. This allowed me to have several streams of development going that were mostly independent of each other. This was invaluable for quick bug fixes, and helped when work was blocked due to a client member being unreachable. Another great advantage was the ability to have my master branch be clean and always be ready for a demo. Git branches differ significantly from SVN branches, in that they are much faster to work with, require less space, and, perhaps most importantly, Git offers better merging capabilities.

I have been doing a lot of writing lately and was interested in automatic versioning so I could see the results of writing over time and how things change. I think that it would be really interesting to see a visualization of a book being written from scratch. Normally you only see the end product; tracking changes over time would allow others to see the sausage being made. This could be useful for teachers to help their students improve their process, for writers to analyze their craft, or for aspiring writers to see how books really get written.

Here's a demo of what I envisioned using a recent blog post that I wrote using the following method.

The system uses git for version history. I also used a Vim hook that checks in the current file on buffer writes:

cabbr autocommit call Autocommit()
fun! Autocommit()
  au BufWritePost * silent !git add <afile>
  au BufWritePost * silent !git commit <afile> -m 'Generated commit'
endfu

This is about the finest grain of editing that I can imagine being useful and that was practical to do. Anything lower-level and you're probably looking at the document as the cursor is moving around. Commits are nearly instantaneous, and you can amend commits to explain complicated changes. Git branching seems to work well with this system. Hence, you can have multiple streams of writing. If you're working with other people, you could be writing a new chapter when you get some feedback on the last chapter which you would like to add. Simply create a branch from the time that you sent the document out, and you should be able to see exactly what the reviewer saw. In addition, authors of collaborative works can use the push/pull functionality to manage copies, which is probably better than emailing documents around. See this page on collaborative writing for more ideas.

Well, it's been a year since I started this blog, and I have been pleasantly surprised by the personal changes that I have seen, as well as other people's responses to my writing.

I appreciated feedback that people gave me over the course of the year, whether through comments or discussions. This helped me realize that I can provide value through writing and that people are actually interested in reading what I am thinking about.

In most languages, regular expressions have symbols to indicate when the first part or last part must match the first or last part of the string or line. These are called anchors. Anchors are usually the caret (^) for matching the beginning of a string, and the dollar sign ($) for the end of the string. Hence:

'abc' =~ /c$/     => true
'abc' =~ /a$/     => false
'abc' =~ /^a/     => true 
'abc' =~ /^c/     => false

I can remember what the anchors are. When I have trouble remembering which is which, I use the following mnemonic:

Found a site that is trying to improve free software documentation. I found this interesting because the idea is related to a previous post that I had about open source tech writers.

It seems that their goal is to improve the documentation of free software products to increase their adoption. You can check this out on the about tab. The discussion on their FLOSS manuals overview reminded me of thoughts that I was having about having some sort of open source documentation or tech writing business. They basically outline the major models for producing content and being compensated for it. There were several sections that focused on the prevailing mindset, technologies, and economics of doing open source (in this case, for free software) documentation. I agree with them that adequate and consistent documentation is something that keeps most open source and free software from being widely adopted on the desktop.