Users sometimes run into situations where they have files they wish to keep under version control but in which they need to maintain perpetual, uncommitted local modifications in their working copy. I have such a use-case myself. I have a Drupal configuration file which I want to keep versioned with the rest of the Drupal code deployed for my site. The site is deployed from a Subversion working copy, and the configuration file has local mods in that working copy which add sensitive information (SQL user/password info). I don't want to accidentally commit that file because if I do so, that sensitive data is now effectively publicized, and I've got to go about changing the SQL user password. Some have suggested that svn:ignore grow to meet this need. I oppose such a move for various reasons (svn:ignore is set on a directory, not on the protected thing itself; "ignore" is a strong verb that would imply to the unlearned that Subversion does nothing with the file -- commit, update, status, log, ...; and so on). But I do support the idea of Subversion growing a new property, more similar to svn:needs-lock than to svn:ignore, which indicates that user has to work a little harder to commit that file. "Harder" is undefined at this junction, but could mean: "The file must be explicitly named in the commit command-line" (though this is probably a non-starter for TortoiseSVN users, where *every* committed thing is named explicitly). "The commit may only change file properties" (so that a user could temporarily remove this blocking property, then commit their file, then reset the property ... but all that is a horrid user experience). "The commit must use --force (or some variant thereof)."