On 22.07.2015 15:51, Bert Huijben wrote: > >> -----Original Message----- >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] >> Sent: woensdag 22 juli 2015 13:43 >> To: Markus Schaber <m.scha...@codesys.com> >> Cc: Grierson, David <david.grier...@sky.uk>; d...@subversion.apache.org; 牛 >> 暁冬 <neoedm...@gmail.com>; users@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
