[
https://issues.apache.org/jira/browse/SVN-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994197#comment-16994197
]
Nathan Hartman commented on SVN-2858:
-------------------------------------
I removed the "bite-sized" label because this issue was discussed briefly on
dev@ and Julian Foad pointed out (1) that "... it's a new feature that isn't
clearly agreed and defined, so it requires proposing and debating a design and
all its interactions with existing behaviour."
(1)
[https://mail-archives.apache.org/mod_mbox/subversion-dev/201910.mbox/%3ccc510c35-4408-2235-b6da-7c6c78d34...@apache.org%3e]
> Support file property which indicates that commit must be manually forced
> -------------------------------------------------------------------------
>
> Key: SVN-2858
> URL: https://issues.apache.org/jira/browse/SVN-2858
> Project: Subversion
> Issue Type: New Feature
> Components: libsvn_wc
> Affects Versions: trunk
> Reporter: C. Michael Pilato
> Priority: Major
> Labels: api
> Fix For: 1.10-consider
>
>
> {noformat:nopanel=true}
> 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)."
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
