Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.11.0
-
None
-
None
Description
"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.