Many ideas have been proposed for version history schemes. They include:
Additionally, users can always archive versions of pages that they wish to protect on their own hard disks, and copies may be archived by Google, or by the InternetArchive?. This allows for limited protection even on sites with no version history. Finally, you can create a manual history by periodically copying a page into archived old versions.
Version history helps a Wiki recover from vandalism, as it is a ReversibleChange. This means users can sleep better. A full history, or KeptPages, provides essentially complete protection from vandals. EditCopy provides limited protection, but does not protect against malicious, knowledgeable attackers. A well as deliberate vandals, version history also protects against accidental "vandalism" from newcomers.
Version history reduces ReworkingProblems: history gives people confidence to make sweeping changes to a page. People are more free to remove content from the current version, because the old versions will remain available for a decent time. Programmers in particular will be aware of how much easier it is to radically modify code with the confidence of a backed-up and versioned source code repository. The same applies to other content, though this is less important if you value CommunityOverContent.
Version history also protects the attackers work. Thus, the attacker can just as easily RevertPage as a defender. This problem can be reduced by making the history hard to obtain (SecurityByObscurity) or by making it only available to priviledged users (AccessLevels).
A full history discourages vandals: because anyone can add rude words and have them stored for posterity, we LimitTemptation. In particular, this discourages vandals from re-adding the same piece of vandalism multiple times in an effort to prevent it ever being fully removed.
A full history is also nice for nostalgia, and for demonstrating that the wiki process works. However, you don't need a full history for this: regular snapshots would serve the same purpose. Alternatively, a ChangeLog? can also provide nostalgia, even without the page contents:  - you can see who's been talking on a page, how active it was, and the edit summaries.
A full history encourages vandalism by preserving it for posterity. This allows "usenet performance artists" and the like to link to the vandalised version to demonstrate their superior humour and sociopathy.
A full history makes it trickier to remove copyright violations. Arguably, copyright violations in history are acceptable, because the VersionHistory is not being "published", but rather is an "editorial tool" to help users build articles. People who complain about copyright violations are typically satisfied with removing the material from the current version, caring much less about the history, so defend against CopyrightParanoia.
Instead of keeping many pages, keep (or pin) one copy of the page. The next time someone pins a page, blow away the old pin. This way, when a page stabilizes--say after a reworking--, you can pin it and continue with discussion.
Make a page exist in non-linear time! Allow users to fork a copy of the page which are also editable (though not necessarily forkable). Only the latest version of the main thread of the page is directly linkable. The rest can only be seen through a protacted "history of this page" view. This will allow versions to be made but corrections to be made to remove embarrassment.
I thought this was interesting, because on EnglishWikipedia we occasionally end up with effective forks: implemented in two ways:
It'd be interesting to have explicit fork support in the software - might help to EnlargeSpace. However, I suspect this would be a case of too much coding work for too little gain.
If the VersionHistory is stored as a graph (or more specifically a directed acyclic graph), then a fork happens when the out-degree of a revision node is greater than one. A merge operation, to remove forks, would create a revision connected to the previous revisions. VersionHistory of a page becomes the path of all connected nodes. Whilst using graphs maybe require some more development time, they do offer some advantages
An example of the relationship between certain wiki features and the way a wiki is the availability of diff. KmWiki e.g. doesn't have diff. Obviously Denham uses it primarily as a PIM, although he invites contributions. But because of the lacking diff in combination with rather long pages it is hard to work with in the usual way. So KmWiki is of little use for communication purposes and remains more or less a PIM. -- HelmutLeitner
I think it interesting that we think of VersionHistory as necessary for authorship credit, when a simple list of contributors would be sufficient. After all, it is pointless to try to attribute every word written in a collaborative effort.
If a wiki newbie comes along and looks at one of this half-assed wiki-wannabe sites, they wouldn't have to be a genius to realise that they should not spend any time contributing content to that website, because any schmuck can com along and permanently destroy all the work. Even worse would be if they didn't realise this, and then some schmuck did destroy all their work. What bothers me is that this gives the wiki concept a bad name. Perhaps all wikis will be tarred with the same brush. -- HarryWood
It would be useful in WikiSciencePublication to be able to retain hard links to past versions of scientific articles if those scientific articles were open to being edited. A review of an article should point to the version of the article that was actually reviewed, not the current version. A good page history system could facilitate hypertext link-mediated access to old versions of articles. -- JohnSchmidt