On Thu, Jul 23, 2015 at 7:16 PM Grierson, David <david.grier...@sky.uk> wrote:
> > -----Original Message----- > > From: Branko Čibej [mailto:br...@wandisco.com] > > Sent: 23 July 2015 07:59 > > To: users@subversion.apache.org > > Subject: Re: Feature request: Save the old file when svn revert > > > > 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; > > 牛 > > 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. > > Guys, > > I think you're needlessly over-complicating things. > > Genuinely - what's wrong with just saving the modified item to a new name > (e.g. $item.reverted)? > > Okay - you /might/ end up with files "cluttering up" a working copy ... so > you remove them if they're troubling you. They won't have been created > unless you explicitly opted-in to have the revert save the modifications. > If you actually wanted to keep them then they're not going to trouble you > If users have to opt-in, and remember to have these modifications saved, they're going to forget, and the data will be lost anyway. I would recommend doing copy foo foo.bak & svn revert foo or svn diff . > ..\diff.patch & svn revert -R . Both scenarios saves a copy of the changes, and then revert, without a coding change. Cheers, Daniel B.
