| January 24, 2012 7:00 pm

If you’ve read parts one and two of this series, you should now have a pretty good understanding as to what version control is and how it can benefit you. You’ve seen how it can be used to keep a backup of your files, synchronize your work between computers, and ensure that you will never suffer the panic of losing your work.

But that’s really only the beginning. Hopefully, you’ve taken things to the next level and feel comfortable digging into the revision history to look at past drafts, make comparisons between documents, or to see how your work has evolved.

Mastering the basics of version control, followed by the finer points, is a fantastic way to be more productive as a writer. By relegating the job of backup and synchronization to a tool, you can spend more time actually writing (and who doesn’t want that). Having the ability to look at how you’re writing has evolved can make you more thoughtful. Both are powerful additions to the scrivener’s arsenal. If you can believe, it though, there is yet another level which allows Subversion to be even more helpful: using it to work collaboratively.

Not a Solitary Endeavor

As the acknowledgements section of any book or article can attest, good writing is the product of many hands. Family, friends, members of a local writing group, editors, research contacts, mentors, and many others are involved in the production of a finished manuscript. They offer feedback, provide support, serve as a sounding board and help to spot errors. Without the additional eyes, ears, and minds, it is unlikely that anything worth reading would ever be published.

With that said, writing collaboratively is frequently painful. Incompatible software makes it difficult to exchange files and collect feedback, important changes can be missed and manuscripts lost, and time is wasted due to editors having the wrong file versions. For all of these reasons, the world of letters has long relied on a time-tested, robust, and extremely slow collaboration process. They print out the draft and send it through the mail. The state of the art at the time of Jane Austen is still the state of the art.

There are many reasons for this (including the technical challenges noted above), but also others. It turns out, using paper for editing and revising is an effective way to work:

  • The process of preparing, sending, and reviewing paper provides time to think carefully about a draft. One of technology’s greatest strengths – the way in which it speeds up communication – is also one of its greatest weaknesses. To develop a thoughtful and careful message sometimes requires thought and contemplation, and for that reason, cannot be rushed. This even goes for when preparing drafts. When you send a draft for someone to review, you are saying, “This is ready for consumption.” It’s not quite the same as just providing someone access to your files and having them go to town.
  • Reading on paper encourages editors to make distinctions between large scale revision and small-scale editing, and, to provide feedback on both to their authors.
  • It makes it easier to collaborate responsibly, with each author taking ownership of a particular section or chapter of the work and providing feedback on the others. When it becomes time to share different drafts, other collaborators are getting something that that’s thought out and cohesive.
  • Reading on paper makes it clear when there might a problem of length. On a computer, it is easy to scan through text without recognizing just how long a particular piece of writing might be. This is usually not a problem when physically sorting pieces of paper.
  • Though I’ve said it, it bears repeating. Sending paper forces an author to create a discrete version for review and for editors to provide feedback on a specific iteration. This difference is important. It results in a qualitatively different product, something that the author has thought through completely. Communicating the “big picture” to an editor or collaborator, before needing to defend decisions about comma placement, results in better writing. An unfortunate reality of editing on the computer is that it is a little too easy to “edit intensely,” that is, correct spelling and punctuation before understanding if there are architectural problems in the narrative.

Version control technologies, however, allow you to replicate many of the same features as a paper based workflow, and to supplement them with the strengths of a digital platform:

  • A user can “lock” specific files, thereby taking ownership of them. When a file is locked, it isn’t possible to submit changes until the file has been unlocked by the original user. This allows for an author or editor to slow down edits and revisions to that one portion of the project while spending time with the draft. It also ensures that co-authors can’t begin providing feedback until the original author is ready to process it.
  • Even though you may want to lock a particular file for ownership reasons, though, doesn’t mean that you don’t want co-authors to have access to it. Subversion can be used to check out an entire writing project at once and to download updates. This means that co-authors can have the most recent drafts of a file for their own reference without having to pester others in group to forward it.
  • Finally, Subversion makes it easy to prepare snapshots of the work for review by others. Much in the same way that you might print out the current version on paper and ship it off to an editor. In the language of version control, these are called “branches.” When ready, a new “branch” of the writing project is created from the main collection of files (sometimes called the trunk) for others to check out and edit. This allows for editors and reviewers to see a cohesive body of work, but for the original authors to continue work on the trunk and then “merge” changes back in when the review has been finished.

When you use Subversion for writing, you get a wonderful hybrid of the paper and digital workflows. You can create the sort of contemplative quiet needed to produce a resonant message, but still have the speed and benefits of electronic communications at hand.

In the next three articles of this series, we’ll look at three of Subversion’s features that create this “wonderful hybrid”:

  • Locks
  • the SVN Log
  • Branches

As we examine these features, we’ll also talk about best practices that can make them invaluable part of your workflow. First up: SVN locks.


No Responses to “Getting Started with Subversion – Part 3.1:
Collaboration Fundamentals”

Care to comment?