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)."
SVN-3028 Always exclude given paths during commit (and possibly update)
