subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Feature request: Save the old file when svn revert
Date Thu, 23 Jul 2015 06:58:41 GMT
On 22.07.2015 15:51, Bert Huijben wrote:
>> -----Original Message-----
>> From: Daniel Shahaf []
>> Sent: woensdag 22 juli 2015 13:43
>> To: Markus Schaber <>
>> Cc: Grierson, David <>;; 牛
>> 暁冬 <>;
>> 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

View raw message