You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by 牛暁冬 <ne...@gmail.com> on 2015/07/20 04:03:57 UTC

Feature request: Save the old file when svn revert

"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.

Thanks
Neoe

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

Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 11:15, Grierson, David wrote:
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
>>>> Sent: woensdag 22 juli 2015 13:43
>>>> To: Markus Schaber <m....@codesys.com>
>>>> Cc: Grierson, David <Da...@sky.uk>; dev@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.

You've probably never been at the receiving end of user complaints, have
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.

Any new conditional feature adds another dimension to compatibility
testing and code complexity. In other words, maintenance costs a lot
more than development in this case, for a feature that's doubtful at best.

> Sure this doesn't handle directory reverts but it's an improvement without any major change to the behaviour of the revert command, no change to the format of working copies or anything else like that. Surely some simple benefit is better than ending up with a feature that's going to take a massive amount of effort to develop and test?

I for one don't intend to support adding more short-cuts and hacks to
the code. There are already too many of them. You have to consider that
once we add your proposed feature, we have to maintain it indefinitely,
even if, in the meantime, we come up with a better solution.

As noted elsewhere, 'svn revert' by itself does nothing; you have to
explicitly tell it what to revert. We can't make a foolproof
command-line client, so why try? Are you going to complain to the bash
developers because 'rm -fr * .o' doesn't do what you intended?

-- Brane

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

Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, Jul 23, 2015 at 7:16 PM Grierson, David <Da...@sky.uk>
wrote:

> > -----Original Message-----
> > From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
> > >> Sent: woensdag 22 juli 2015 13:43
> > >> To: Markus Schaber <m....@codesys.com>
> > >> Cc: Grierson, David <Da...@sky.uk>;
> dev@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.

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

Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 11:15, Grierson, David wrote:
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
>>>> Sent: woensdag 22 juli 2015 13:43
>>>> To: Markus Schaber <m....@codesys.com>
>>>> Cc: Grierson, David <Da...@sky.uk>; dev@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.

You've probably never been at the receiving end of user complaints, have
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.

Any new conditional feature adds another dimension to compatibility
testing and code complexity. In other words, maintenance costs a lot
more than development in this case, for a feature that's doubtful at best.

> Sure this doesn't handle directory reverts but it's an improvement without any major change to the behaviour of the revert command, no change to the format of working copies or anything else like that. Surely some simple benefit is better than ending up with a feature that's going to take a massive amount of effort to develop and test?

I for one don't intend to support adding more short-cuts and hacks to
the code. There are already too many of them. You have to consider that
once we add your proposed feature, we have to maintain it indefinitely,
even if, in the meantime, we come up with a better solution.

As noted elsewhere, 'svn revert' by itself does nothing; you have to
explicitly tell it what to revert. We can't make a foolproof
command-line client, so why try? Are you going to complain to the bash
developers because 'rm -fr * .o' doesn't do what you intended?

-- Brane

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

Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, Jul 23, 2015 at 7:16 PM Grierson, David <Da...@sky.uk>
wrote:

> > -----Original Message-----
> > From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
> > >> Sent: woensdag 22 juli 2015 13:43
> > >> To: Markus Schaber <m....@codesys.com>
> > >> Cc: Grierson, David <Da...@sky.uk>;
> dev@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.

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
> >> Sent: woensdag 22 juli 2015 13:43
> >> To: Markus Schaber <m....@codesys.com>
> >> Cc: Grierson, David <Da...@sky.uk>; dev@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.

Sure this doesn't handle directory reverts but it's an improvement without any major change to the behaviour of the revert command, no change to the format of working copies or anything else like that. Surely some simple benefit is better than ending up with a feature that's going to take a massive amount of effort to develop and test?

Dg.




Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@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.s@daniel.shahaf.name]
> >> Sent: woensdag 22 juli 2015 13:43
> >> To: Markus Schaber <m....@codesys.com>
> >> Cc: Grierson, David <Da...@sky.uk>; dev@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.

Sure this doesn't handle directory reverts but it's an improvement without any major change to the behaviour of the revert command, no change to the format of working copies or anything else like that. Surely some simple benefit is better than ending up with a feature that's going to take a massive amount of effort to develop and test?

Dg.




Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by Branko Čibej <br...@wandisco.com>.
On 22.07.2015 15:51, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
>> Sent: woensdag 22 juli 2015 13:43
>> To: Markus Schaber <m....@codesys.com>
>> Cc: Grierson, David <Da...@sky.uk>; dev@subversion.apache.org; 牛
>> 暁冬 <ne...@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

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

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: woensdag 22 juli 2015 13:43
> To: Markus Schaber <m....@codesys.com>
> Cc: Grierson, David <Da...@sky.uk>; dev@subversion.apache.org; 牛
> 暁冬 <ne...@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.

	Bert


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

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: woensdag 22 juli 2015 13:43
> To: Markus Schaber <m....@codesys.com>
> Cc: Grierson, David <Da...@sky.uk>; dev@subversion.apache.org; 牛
> 暁冬 <ne...@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.

	Bert


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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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).

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

For svn we could certainly stash the local filecontents in the pristine
store.  They'd have refcount of zero so the next cleanup pass will
delete them.  Storing them this way is not free (it costs disk space, so
for example people using 'revert' often will experience a behaviour
change).  And if we do this, we'll have to think of the interface for
retrieving files from there.

So, I'm not sure whether we want to do this, and what the interface
might look like, but if we chooes to do this, the pristine store might
be an element of the solution.

Cheers,

Daniei

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber@codesys.com]
> Sent: 21 July 2015 14:01
> To: Grierson, David; dev@subversion.apache.org
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: AW: Feature request: Save the old file when svn revert
> ...
> 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...

Good question ...

The equivalent in ClearCase was a "cleartool uncheckout": http://www-01.ibm.com/support/knowledgecenter/SSSH27_7.1.1/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_uncheckout.htm?cp=SSSH27_7.1.1%2F9-0-0-1-69

This has the -kee/p and -rm options on the command:

> –kee/p
> Preserves the contents of the checked-out version under a file-name of the form element-name.keep
> (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on).
>
> –rm
> Does not preserve the contents of the checked-out version. Thus, any edits that had been made to
> the checked-out version are lost.

The default action is to prompt the user for what to do with the lost changes:

> Cancel the checkout of file element util.c.

$ cleartool uncheckout util.c
Save private copy of "util.c"? [yes] no
Checkout cancelled for "util.c".

I guess the equivalent in git is the reset command: http://git-scm.com/docs/git-reset

This seems to have three key options:

> --hard
> Resets the index and working tree. Any changes to tracked files in the working tree since <commit>
> are discarded.
>
> -merge
> Resets the index and updates the files in the working tree that are different between <commit> and
> HEAD, but keeps those which are different between the index and working tree (i.e. which have changes
> which have not been added). If a file that is different between <commit> and the index has unstaged
> changes, reset is aborted.
>
> --keep
> Resets index entries and updates files in the working tree that are different between <commit> and
> HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.

So _similar_ (but more quirky IMHO) operation to ClearCase.

Dg.
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber@codesys.com]
> Sent: 21 July 2015 14:01
> To: Grierson, David; dev@subversion.apache.org
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: AW: Feature request: Save the old file when svn revert
> ...
> 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...

Good question ...

The equivalent in ClearCase was a "cleartool uncheckout": http://www-01.ibm.com/support/knowledgecenter/SSSH27_7.1.1/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_uncheckout.htm?cp=SSSH27_7.1.1%2F9-0-0-1-69

This has the -kee/p and -rm options on the command:

> –kee/p
> Preserves the contents of the checked-out version under a file-name of the form element-name.keep
> (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on).
>
> –rm
> Does not preserve the contents of the checked-out version. Thus, any edits that had been made to
> the checked-out version are lost.

The default action is to prompt the user for what to do with the lost changes:

> Cancel the checkout of file element util.c.

$ cleartool uncheckout util.c
Save private copy of "util.c"? [yes] no
Checkout cancelled for "util.c".

I guess the equivalent in git is the reset command: http://git-scm.com/docs/git-reset

This seems to have three key options:

> --hard
> Resets the index and working tree. Any changes to tracked files in the working tree since <commit>
> are discarded.
>
> -merge
> Resets the index and updates the files in the working tree that are different between <commit> and
> HEAD, but keeps those which are different between the index and working tree (i.e. which have changes
> which have not been added). If a file that is different between <commit> and the index has unstaged
> changes, reset is aborted.
>
> --keep
> Resets index entries and updates files in the working tree that are different between <commit> and
> HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.

So _similar_ (but more quirky IMHO) operation to ClearCase.

Dg.
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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).

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

For svn we could certainly stash the local filecontents in the pristine
store.  They'd have refcount of zero so the next cleanup pass will
delete them.  Storing them this way is not free (it costs disk space, so
for example people using 'revert' often will experience a behaviour
change).  And if we do this, we'll have to think of the interface for
retrieving files from there.

So, I'm not sure whether we want to do this, and what the interface
might look like, but if we chooes to do this, the pristine store might
be an element of the solution.

Cheers,

Daniei

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

Posted by Markus Schaber <m....@codesys.com>.
Hi,

Von: Grierson, David [mailto:David.Grierson@sky.uk]
> From: 牛暁冬 [mailto:neoedmund@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@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.


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

Posted by Markus Schaber <m....@codesys.com>.
Hi,

Von: Grierson, David [mailto:David.Grierson@sky.uk]
> From: 牛暁冬 [mailto:neoedmund@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@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.


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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> Sent: 21 July 2015 17:08
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> That way you still force millions of users to behave differently now
> because one user made a mistake once. I don't see the point in why
> revert should break backwards compatibility ...

Backwards compatibility is a better (and valid) argument for not changing the behaviour of revert.

I agree, for that reason, it should be an opt-in. Perhaps with a --keep option.

(Hey look rational debate can change opinions on the Internet ... who knew ;)

Dg.


Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> Sent: 21 July 2015 17:08
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> That way you still force millions of users to behave differently now
> because one user made a mistake once. I don't see the point in why
> revert should break backwards compatibility ...

Backwards compatibility is a better (and valid) argument for not changing the behaviour of revert.

I agree, for that reason, it should be an opt-in. Perhaps with a --keep option.

(Hey look rational debate can change opinions on the Internet ... who knew ;)

Dg.


Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Grierson, David,
am Dienstag, 21. Juli 2015 um 17:48 schrieben Sie:

> If you don't specify prompt.
> If you do specify then you're saying one way or the other which you explicitly want.

That way you still force millions of users to behave differently now
because one user made a mistake once. I don't see the point in why
revert should break backwards compatibility instead of providing
opt-in, that could only be argued if creating backups is providing
benefit to most users, which two of us are already doubting. Looking
at git checkout, I don't see the requested behavior as well.

I'll keep my vote for opt-in.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> Sent: 21 July 2015 16:09
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> > I would very much prefer if this could be an option that is not enabled
> > by default.
>
> +1
>

I think how ClearCase handles it is best:

If you don't specify prompt.
If you do specify then you're saying one way or the other which you explicitly want.

Best of both worlds?

Dg.


Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by "Grierson, David" <Da...@sky.uk>.
> -----Original Message-----
> From: Thorsten Schöning [mailto:tschoening@am-soft.de]
> Sent: 21 July 2015 16:09
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> > I would very much prefer if this could be an option that is not enabled
> > by default.
>
> +1
>

I think how ClearCase handles it is best:

If you don't specify prompt.
If you do specify then you're saying one way or the other which you explicitly want.

Best of both worlds?

Dg.


Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag OBones,
am Dienstag, 21. Juli 2015 um 11:06 schrieben Sie:

> I would very much prefer if this could be an option that is not enabled
> by default.

+1

I do revert frequently while merging branches and testing things and
would hate it to have to additionally manually remove files which I
don't need. "svn revert" reverts files, if I'm not sure I want that I
copy things N times somewhere or else, but in 99% I'm sure. And the
other 1% could as well be a mislead "rm -rf" in the wrong directory or
a crashing HDD or whatever, wouldn't make any difference.

I bet that the feature request is the result of a wrongly applied "svn
revert", the frustration about that and I do understand that. But bad
things happen all the time, so if one wants to have backups before
reverting, this should be opt-in in my opinion.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


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

Posted by Eric Johnson <er...@tibco.com>.
Seems to me that stashing the before-reverted copies could go into some
"recycle bin" / "trash" folder underneath the .svn folder at the root of
the working copy. And by default, the client could clean out files
time-stamped over a month old, so it doesn't perpetually grow. Cleanup
could happen on "commit" operations.

Then a new options could be added to the svn revert command. I'm thinking:
 - revert --undo path/to-local/file # undoes the revert
 - revert --list-undoable # lists all the available files with a revert
that can be undone

This has the advantages of not changing the existing semantics of the
revert operation, doesn't clutter up the directories of the working copy,
and self-cleans.

Eric.

On Tue, Jul 21, 2015 at 9:14 AM, Andreas Mohr <an...@lisas.de> wrote:

> On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
> > Grierson, David wrote:
> > >I completely understand that the action of sending to the Recycle Bin
> (in TortoiseSVN) is very system specific.
> > >
> > >To simply rename the item being reverted as $item.$backupSuffix before
> then restoring the pristine item is presumably not that system specific?
> > >
> > >Having this functionality in the base tool would then provide a benefit
> to all users and not just those using a specific IDE.
> > I would very much prefer if this could be an option that is not enabled
> by
> > default. I mean, this would clutter the filesystem with many files that
> one
> > would have to delete manually, especially when considering that some of
> us
> > are using less than optimal filesystems when it comes down to lots of
> small
> > files.
>
> This seems to hint that the revert-backup item
> possibly should *not* be placed in the same directory as the item,
> but rather in an "alternate tree base"
> (creating random similarly-named files next to each other in unexpected
> ways
> seems just asking for trouble,
> and lots of it - think build system mechanisms, other automatic
> handling, ...).
>
>
> Knee-jerk sample (hard-coded, non-elegant, read: day-to-day occurrence ;):
>
> unit_test1.c
> unit_test2.c
> unit_test1.c.revert_backup
>
> "cp -a unit_test* some_dir/"
> "some_dir/tool unit_test*"
>
>
> One might even implement this as a config option ("revert tree base
> directory"),
> and if left unspecified/empty
> svn could fall back to having .reverted files local,
> or another mode might be to record this within the local .svn dirs.
>
> Andreas Mohr
>
> --
> GNU/Linux. It's not the software that's free, it's you.
>

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

Posted by Andreas Mohr <an...@lisas.de>.
On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
> Grierson, David wrote:
> >I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific.
> >
> >To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific?
> >
> >Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE.
> I would very much prefer if this could be an option that is not enabled by
> default. I mean, this would clutter the filesystem with many files that one
> would have to delete manually, especially when considering that some of us
> are using less than optimal filesystems when it comes down to lots of small
> files.

This seems to hint that the revert-backup item
possibly should *not* be placed in the same directory as the item,
but rather in an "alternate tree base"
(creating random similarly-named files next to each other in unexpected ways
seems just asking for trouble,
and lots of it - think build system mechanisms, other automatic
handling, ...).


Knee-jerk sample (hard-coded, non-elegant, read: day-to-day occurrence ;):

unit_test1.c
unit_test2.c
unit_test1.c.revert_backup

"cp -a unit_test* some_dir/"
"some_dir/tool unit_test*"


One might even implement this as a config option ("revert tree base directory"),
and if left unspecified/empty
svn could fall back to having .reverted files local,
or another mode might be to record this within the local .svn dirs.

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.

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

Posted by "Grierson, David" <Da...@sky.uk>.
Apologies for the previous top-posting ... I hate Outlook sometimes.

> -----Original Message-----
> From: OBones [mailto:obones@free.fr]
> Sent: 21 July 2015 10:06
> To: Grierson, David; Andreas Stieger
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> Grierson, David wrote:
> > I completely understand that the action of sending to the Recycle Bin
> (in TortoiseSVN) is very system specific.
> >
> > To simply rename the item being reverted as $item.$backupSuffix before
> then restoring the pristine item is presumably not that system specific?
> >
> > Having this functionality in the base tool would then provide a benefit
> to all users and not just those using a specific IDE.
> I would very much prefer if this could be an option that is not enabled
> by default. I mean, this would clutter the filesystem with many files
> that one would have to delete manually, especially when considering that
> some of us are using less than optimal filesystems when it comes down to
> lots of small files.

Presumably only if you're doing a lot of reverts and surely that's going to be negligible compared with the existing hit you're receiving from the working copy files.

Dg.
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by OBones <ob...@free.fr>.
Grierson, David wrote:
> I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific.
>
> To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific?
>
> Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE.
I would very much prefer if this could be an option that is not enabled 
by default. I mean, this would clutter the filesystem with many files 
that one would have to delete manually, especially when considering that 
some of us are using less than optimal filesystems when it comes down to 
lots of small files.

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

Posted by "Grierson, David" <Da...@sky.uk>.
I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific.

To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific?

Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE.

--
David Grierson - SDLC Tools Specialist
Sky Broadcasting - Customer Business Systems - SDLC Tools
Email: david.grierson@sky.uk
Watermark Building, Alba Campus, Livingston, EH54 7HH


> -----Original Message-----
> From: Andreas Stieger [mailto:Andreas.Stieger@gmx.de]
> Sent: 21 July 2015 09:38
> To: Grierson, David
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> Hello,
>
> David Grierson wrote:
> > > "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@subversion.apache.org list to see
> if it's something that they've considered previously.
>
> Actually a feature in at least one GUI client:
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-
> settings.html#tsvn-dug-settings-dialogs
> Otherwise it's rather platform specific to implement, and may be better
> suited for integrated clients.
>
> Andreas
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 21 July 2015 at 11:38, Andreas Stieger <An...@gmx.de> wrote:
> Hello,
>
> David Grierson wrote:
>> > "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@subversion.apache.org list to see if it's something that they've considered previously.
>
> Actually a feature in at least one GUI client:
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-dialogs
> Otherwise it's rather platform specific to implement, and may be better suited for integrated clients.
>
I think best solution is to move reverted files to Recycle Bin if it
present on platform.

Many platforms seems to have Recycle Bin concept these days: Recycle
Bin on Windows, ~/.Trash on Ubuntu and Trash on Mac OS [1]

[1] http://www.hardcoded.net/articles/send-files-to-trash-on-all-platforms

-- 
Ivan Zhakov

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

Posted by Andreas Stieger <An...@gmx.de>.
Hello,

David Grierson wrote:
> > "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@subversion.apache.org list to see if it's something that they've considered previously.

Actually a feature in at least one GUI client:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-dialogs
Otherwise it's rather platform specific to implement, and may be better suited for integrated clients.

Andreas

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

Posted by "Grierson, David" <Da...@sky.uk>.
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@subversion.apache.org list to see if it's something that they've considered previously.

David.
--
David Grierson - SDLC Tools Specialist
Sky Broadcasting - Customer Business Systems - SDLC Tools
Email: david.grierson@sky.uk
Watermark Building, Alba Campus, Livingston, EH54 7HH


> -----Original Message-----
> From: 牛暁冬 [mailto:neoedmund@gmail.com]
> Sent: 20 July 2015 03:04
> To: users@subversion.apache.org
> Subject: Feature request: Save the old file when svn revert
>
> "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.
>
> Thanks
> Neoe
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

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

Posted by "Grierson, David" <Da...@sky.uk>.
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@subversion.apache.org list to see if it's something that they've considered previously.

David.
--
David Grierson - SDLC Tools Specialist
Sky Broadcasting - Customer Business Systems - SDLC Tools
Email: david.grierson@sky.uk
Watermark Building, Alba Campus, Livingston, EH54 7HH


> -----Original Message-----
> From: 牛暁冬 [mailto:neoedmund@gmail.com]
> Sent: 20 July 2015 03:04
> To: users@subversion.apache.org
> Subject: Feature request: Save the old file when svn revert
>
> "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.
>
> Thanks
> Neoe
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.