Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +0000: > All other commands need a --force or other explicit user decision to > override user changed data, but the whole purpose of the "svn revert" > command is to undo local changes - putting a --force option or > something similar seems like a bit of contradiction.
Note that 'svn revert' without further arguments does nothing and errors out; you must name explicitly what will be reverted. (Even with '-R' you still need to specify a target directory.) > How do the other RCSes handle this situation? Maybe we can learn > some ideas for a nice(r) UI there... In Git, if you add a file to the index, you can generally 'cat-file blob' it out of there for a while later if you know its hash (eg, if you have the header of a diff of that file, as headers mention the hash). Ditto for local commits, you can get them from the reflog for a while later (until a garbage collection pass). > On the other hand, I'm not an SVN core developer, so it's just my > personal opinion. For svn we could certainly stash the local filecontents in the pristine store. They'd have refcount of zero so the next cleanup pass will delete them. Storing them this way is not free (it costs disk space, so for example people using 'revert' often will experience a behaviour change). And if we do this, we'll have to think of the interface for retrieving files from there. So, I'm not sure whether we want to do this, and what the interface might look like, but if we chooes to do this, the pristine store might be an element of the solution. Cheers, Daniei