Writing and Managing Text or How I came to love source control.
Previously published*
The story of the lost script, the lost manuscript, the proof eaten by the dog are all both stereotypical and common for writers whichever tool they've used to record their words, whether cuneiform, paint, ink, print or electromagnetic bits. For most writers that's been their own responsibility and every one has their own learning experience when they had no mechanism of copying, archiving or backing up their words.
Only recently I read the story of a writer who had had their hard drive go down and needed a forensic data recovery service to get back his manuscript. Now, chastened, he's devised the same kind of backup regime that any information system or IT department has to go through. And its not much fun.
Every writer has a workflow
Backing up the current copy is fine onto some other device but will you be able to read and restore from that device, should you keep multiple copies? It all seems like a lot of work and worry, perhaps even more worrying than not having any backups and just trusting things to work. If you're a writer that uses pen or pencil and notebooks, whether they have elastic bands around them or not then you might be feeling a little smug right now. Until you come to share your manuscript, need it transcribed and then whether galley proofs are printed and hand annotated or not they will likely be on an electronic system of some kind.
Every writer has a workflow. It might include coffee, cats, a particular desk and chair and a favourite pebble to play with when plotting but if successful it will be consistent. If there's a process or set of processes within that workflow that gets in the way or forms some kind of hurdle or gumption leakage then the chances are it won't feel very comfortable and it might get dropped more often than it's performed. If that is your backup process then you're banking your risk all the time.
I'm going to work through a process that should fit any writer's workflow who works on their own and likely uses software and a computer as their writing, reference and research tool. If you're a writer using a publishing or content platform then this kind of process is probably already done for you. But maybe not.
I'm not going to specifically mention or recommend tools so much as the category of tools. If anyone wants recommendations or advice they can ask me directly. The principle I use is that any tool must have a well defined function and have a positive effect on the outcome (writing things) and not be a bump in the road.
I tend to write using a text editor, it's a very sophisticated text editor but all it produces is text. There is no special format or encoding (unless you count UTF-8). This workflow suits plain text but it works for any formatted file such as MS Word, OpenOffice Writer or Scrivener as well. My editor also incrementally saves in the background which means if the power fails or I reboot unthinkingly then all is as it was when I left it. This too is a common feature. But it is not saving a redundant copy, a backup or archive in another location to protect against losing the primary copy due to media or machine failure.
I could use some kind of automated backup to copy to non local storage, into the cloud using one of the many cloud services. I do use cloud as a general store and that along with my local synchronised store is certainly good enough but it doesn't quite get me what I want which is a structured copy which includes all my decisions, edits and rewrites. A true archive.
Source Control
Now why I want that comes from both my technical coding background but also from my OCD about not losing anything, ever. And I scratch that itch and remove all care about archiving, managing hardware and everything else by using source control.
Source control, as a tool, is about recording all of the different changes in a file and stored in a repository in such a way that it can be reconstituted at any point in its history, it is a versioned copy.
The reason that suits me is that there are different phases to the process. At the start of any project the majority of the changes will be both incremental and an accretion. I'll write more stuff. At some reasonable frequency (generally when the flow of typing pauses), I'll actively save the file and add the latest changes to the repository which is called committing. That commit is to the local repository, its on my laptop, I then push that commit to the remote repository flying around in the internet. And then I carry on writing until at some point, perhaps the end or perhaps when I begin to feel a little lost in the writing and I go back to review and edit.
the text becomes both plastic and stable at the same time
This second phase is reading the text, editing and correcting, rewriting, scrapping and deleting parts, cutting and pasting, rearranging; all the manipulations you can make to text. At the end of each change I commit and push and all of the changes are saved in the order they were made and in the context of the whole corpus at the time. Any of those atomic changes can be reverted as if they haven't happened or further changed and morphed and all of the saved stages are preserved in the amber of the source control repository. The most important quality of this is that it fits naturally into the process of writing and editing.
In using this as part of the process the text becomes both plastic and stable at the same time. Any change is possible, all revisions are available. This is part of the fluidity that those that use handwriting get with pen, ink and paper. Insertions are made or indicated within the text, the text becomes a corpus of all the changes. At the cost of deciphering when it comes to editing. Using source control you always have a clean copy.
The proof of any process requires some commitment but if you try this out and persevere, just a little, it will reward you, probably in ways you had not considered. I'm interested in hearing from anyone that tries it for themselves or perhaps already uses a similar workflow.
For the Lifehack.
Search for source control service, if you use a remote service then it will also recommend a client app for your operating system. The two most common dialects of source control are 'git' and 'subversion', with git having overtaken subversion in the market. My tiny example uses git but the process is very similar in other tools. In the public market the largest share would include GitHub, GitLab, SourceForge. All of them let you manage your repository using your browser and all recommend or provide desktop apps.
For your client software pick the style that is most familiar to you. If you use apps pick one of the desktop clients, whichever one you choose it will be a similar process. If you're comfortable with the command line then installing your local repository will give you a command line client.
If it helps in making the decision to try this out many of the tools are open source and repositories are no cost for low volume use.
Documenting a Work's Process for Authors, Editors and Librarians
This is a subject for another essay but because this is a tool designed to store all of the changes in a file in a versioned way it also allows for the annotation of those changes. Generally, as it happens, you have to comment on the change in order to commit it but this is often a default comment, 'Update How I came to love source control.', for example. Used properly this can be extremely powerful ;for the author(s), to document their progress to remind themselves why they surgically removed an entire chapter or section, or perhaps put it back; for the editor to help the author in the process of preparing for publishing; for the librarian and archivist in understanding in the future how a work was conceived, written, edited and published.
