AW: Feature request: Save the old file when svn revert

Hi,

Von: Grierson, David [mailto:David.Grierson_at_sky.uk]
> From: 牛暁冬 [mailto:neoedmund_at_gmail.com]
> > "svn revert" will delete the local changes and nowhere to find,
> > which is dangerous.
> > I suggest the default behaiver should be save the local changed
> > file(if any) to "filename.local" and do the revert.
>
> That's actually not a bad idea ... I've been burnt by this one a
> couple of times myself.
>
> Probably worth raising it with the dev_at_subversion.apache.org list to
> see if it's something that they've considered previously.

I'm not really sure what to think about this one...

In the end, the whole purpose of "svn revert" is to drop the local
changes and *revert* everything back to the state the repository has.

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.

On the other hand, I'm not an SVN core developer, so it's just my
personal opinion.

How do the other RCSes handle this situation? Maybe we can learn
some ideas for a nice(r) UI there...

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Received on 2015-07-21 15:01:32 CEST