[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Change "revert" behaviour

From: Greg Stein <gstein_at_lyra.org>
Date: 2004-11-29 18:01:57 CET

On Mon, Nov 29, 2004 at 04:43:11PM -0000, Max Bowsher wrote:
> Greg Stein wrote:
>...
> >Make paranoid the default. We always want to choose safe defaults. If
> >somebody wants a bit more speed at the cost of "not [necessarily] as
> >safe", then they can use a flag.
>
> I have to disagree. If we followed that argument, we would want to make the
> always-checksum behaviour the default for commit and diff and all the
> others too.

Revert throws out changes. commit and diff do not. Tho, arguably, if
you make a change and it doesn't get committed, then that isn't too
happy either. But those changes *are* still there.

> >In this particular case, the person doing the merges knows there
> >aren't any local mods, so they could do something like:
> >
> > $ svn revert --skip-safety-checks --recursive .
>
> No, no. It's not about whether there are local mods or not. It's about the
> weird edge case that there might be local mods, but the file time is still
> equal to that reported in the .svn/entries file.

It *is* about the local mods. The original post was "I've got some
changes and I just want to get rid of them." The user *knows* nothing
funny is going on and just wants to toss them.

The default command looks for those edge cases. The user has to take
proactive steps to skip the exhaustive checks.

> Since we don't consider that important for other subcommands, why should
> revert be special?

Because it is very destructive.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 29 18:02:59 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.