[jira] [Commented] (SVN-2858) Support file property which indicates that commit must be manually forced

["Nathan Hartman (Jira)" <ji...@apache.org>]

    [ 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-7c6c78d343c8@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)