...
Sometimes (who am I kidding?) we have a few false starts when writing the introduction or background sections of a paper. Occasionally out comes a brilliant paragraph that would help provide strong conceptual foundations for a different paper than the one we are currently trying to write. Learning to write is, among other things, learning to delete text that doesn’t belong. Having had the experience of deleting text later fondly remembered as the best thing I ever wrote, I am reluctant to completely erase it. I might instead move it to the bottom of the document or and it will get carried forward to new versions. Alternatively you might save it in a separate file. If you save it under a different file name, you'll want to keep a document that indexes your saved files so that you can find the deleted text later when you want it.
If you use a cloud storage system like Box (UTBox) or Dropbox to store your files, the system likely automatically keeps past versions of your files so that you do not need to save files under a new name to keep an archive. For example, UTBox saves up to 100 previous versions of a file. You can see the version history by going to your folder in UTBox and clicking on the file. A version history will appear on the right side of the page. If you want to keep a version more than 100 saves ago, you'll want to archive it somewhere using a different name, but this would likely reduce the number of files on your harddrive. This approach does not make it especially easy to see what changed between versions.
Allowing computers to keep a version history helps to keep directories clean and reduces the risk of having to reconcile independent revisions of the manuscript. In the past, I and my collaborators usually created My collaborators often create new versions of a manuscript with every editing session, usually often in combination with changes tracked. This belt and suspenders approach helps helped to ensure that we don't lose text, but it has some downsides too. First, track changes makes the file messy and difficult to read. It's, of course, possible to look at the document without changes tracked by selecting "no markup" on the "review" toolbar, but it is not possible to show just the changes since the last time I edited the file unless everyone accepts all changes before starting their writing session. In my experience, co-authors are slow to accept changes and we end up with text in 24 different colors of text each meaning nothing to metherefore it is still difficult to tell what changed between this draft and the previous one. Second, your my directory becomes became crowded with multiple versions of files. This increases the risk that you I will edit the wrong version of the file. For example, maybe yesterday a co-author I looked at a version of the text as it was last month, mindlessly corrected a typo, and "saved" it. Then you start your my co-author starts her day by sorting the files by date modified and select selects the most recently edited file to start your her writing session. Or maybe youI've anticipated this problem and have named your my files in a way that allows you me to find the most recent file by sorting by name and not just by date of most recent save. Assuming that you my collaborators and your collaborators I execute this system perfectly, you I still have a lot of files with similar names sitting in your my cluttered directory and it takes effort to make sure you I open the right one. If you For this reason, I prefer to use a cloud storage system like and let Box (UTBox) or Dropbox to store your files, the system likely automatically keeps past versions of your files so that you do not need to save files under a new name to keep an archive. For example, UTBox saves up to 100 previous versions of a file. You can see the version history by going to your folder in UTBox and clicking on the file. A version history will appear on the right side of the page. If you want to keep a version more than 100 saves ago, you'll want to archive it somewhere using a different name, but this would likely reduce the number of files on your harddrive.
Alternatively, you could keep all of your text files, including the text of the article, on GitHub. You check in your text like you check in your code and you can use git diff or your GUI tool to see changes between versions of the text. You have just one version of the file, the most recent one, in your directory. Thus far, for me, a barrier to keeping text files in GitHub is that I cannot link references in a text file to the zotero database. There are some potential advantages of keeping text in GitHub however. For example, your archive would allow you to see the contemporaneous state of the code and state of the manuscript and this would indirectly serve as some documentation for the code. If we overcome the problem with references and develop systems for keeping our text in GitHub, we will report back.