> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: woensdag 22 juli 2015 13:43
> To: Markus Schaber <m.schaber_at_codesys.com>
> Cc: Grierson, David <David.Grierson_at_sky.uk>; dev_at_subversion.apache.org; 牛
> 暁冬 <neoedmund_at_gmail.com>; users_at_subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> 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).
Adding it to the index, is usually done by something like commit. In that
case I don't think you really need to stash the actual file locally, as you
can just get it with 'svn cat' (probably after finding some revision with
svn log)
The local version of the file might have local changes though...
If you would store that one in the pristine store, it would have some sha-1
hash...
But I doubt the user would know that hash, and without that he/she would be
unable to retrieve it, unless we build some UI.
In that case I would start by looking at the UI.
Bert
Received on 2015-07-22 15:53:09 CEST