On 22.07.2015 15:51, Bert Huijben wrote:
>
>> -----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.
What we really want here is "svn stash", i.e., an equivalent to "git
stash". In other words, I would not consider changing how "svn revert"
works; instead, I'd like to design a new working copy feature that does
more useful stuff than just saving away local modifications on revert.
Since any such saving would require a working copy format change to be
even remotely useful, we may as well consider introducing whole-hawg
working copy state management.
-- Brane
Received on 2015-07-23 08:59:01 CEST