On Thu, Jul 23, 2015 at 7:16 PM Grierson, David <David.Grierson_at_sky.uk>
wrote:
> > -----Original Message-----
> > From: Branko Čibej [mailto:brane_at_wandisco.com]
> > Sent: 23 July 2015 07:59
> > To: users_at_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.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;
> > 牛
> > 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.
Received on 2015-07-23 23:18:27 CEST