On 23.07.2015 11:15, Grierson, David 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.
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
Received on 2015-07-23 11:47:28 CEST