You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Nathan Hartman (Jira)" <ji...@apache.org> on 2019/12/12 04:52:00 UTC

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

     [ https://issues.apache.org/jira/browse/SVN-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Hartman updated SVN-2858:
--------------------------------
    Labels: api  (was: api bite-sized)

> 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)