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
Received on 2015-07-22 13:43:12 CEST