Currently, there are two revision-control options when saving a node: 1. Overwrite the latest revision. 2. Create a new revision. I think #1 has very little value. Argument for allowing #1: * Slightly smaller database size Arguments for only allowing #2: * Fewer site administration options * Cleaner node-editing pages for node administrators * Less confusion over what checking the box does: "Aren't I creating a new revision of the node even if I don't check it?" * Less node-saving code. Currently, many modules have to redirect new revisions to the node creation code. We can dump hook_update if every node save is a new revision. A module can still check if it's really a new node if the module needs to do anything special. * Better-tested node-saving code. I sometimes find modules that don't work properly with revisions. * Site administrators will have more options to recover from mistakes without having to remember to check a box or configure every content type to create new revisions by default. * Using modules that automatically clean up old revisions can cap the increase in database size. * Files are shared across revisions, so there's little increase in disk space. * There's no performance impact to keeping old revisions around. A JOIN on {node_revisions} happens regardless of whether multiple revisions are in use. * Lots of users are accustomed to editing Wikipedia, so seeing a revisions tab shouldn't be scary to new users of Drupal. * Even if they don't know how to use the revisions tab, the site will function exactly as if they didn't use revisions. Even cheap shared hosts allow ridiculous amounts of space, so database size isn't that important anymore. Unless there's a really compelling argument for leaving #1 around, I'd like to create an issue to eliminate the ability to save a node without creating a new revision in Drupal 6.