[
https://issues.apache.org/jira/browse/SVN-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad reassigned SVN-4798:
--------------------------------
Assignee: Julian Foad
> svn revert: option to remove added items from disk
> --------------------------------------------------
>
> Key: SVN-4798
> URL: https://issues.apache.org/jira/browse/SVN-4798
> Project: Subversion
> Issue Type: Improvement
> Components: cmdline client
> Affects Versions: 1.11.0
> Reporter: Julian Foad
> Assignee: Julian Foad
> Priority: Major
>
> "svn revert" normally un-schedules a locally *added* file or dir (scheduled
> for addition, not a copy), leaving it unversioned. This is the opposite of
> "svn add", and is considered the "safer" and "correct" of the two possible
> behaviours: see SVN-741.
> In the case of a *copied* file or directory (scheduled for "addition with
> history"), "svn revert" has deleted it from disk since SVN-3101.
> Sometimes, however, the user knows that the added files and dirs do not
> contain valuable data and should be deleted as part of the revert. For
> example, if they have been created by a merge, or by a foreign-repository
> copy, or by a script, or simply that the user wrote the content and no longer
> wants it.
> This issue is for an *option* for revert to also delete from disk any
> schedule-add items that it reverts.
> Why? Or why aren't existing work-arounds good enough? A work-around like
> running "revert" first and then "svn cleanup --remove-unversioned" is too
> broad: it deletes other unversioned files as well as the ones that were adds.
> This task should be simple, and I don't see any correct and simple
> work-around.
> Furthermore, the corresponding option has been available in the API since
> Subversion 1.11 as svn_client_revert4(added_keep_local=FALSE), because it was
> needed within the implementation of shelving. It just is not yet exposed in
> the CLI.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
