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

Re: [PATCH] --reverse option to invert -c/--change

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-01-14 00:29:10 CET

On Fri, 13 Jan 2006, Brian W. Fitzpatrick wrote:

>
> On Jan 13, 2006, at 2:36 PM, Greg Hudson wrote:
>
> >On Fri, 2006-01-13 at 14:23 -0600, Brian W. Fitzpatrick wrote:
> >>>(Yeah, I know, "svn merge -c N --reverse" to roll back a change. I
> >>>don't think rollbacks are all that common.)
> >[...]
> >>I think that if we made it easier ('-c REV' is the first step in that
> >>direction, '-c NEGATIVE_REV' is another huge step in that direction),
> >>then we'd see people rolling back very often.
> >
> >I disagree that there's a frequent call for rollback, but we can't
> >settle that on the dev list.
>
> Agreed.
>
> >>BTW, one use case for rolling back is the desire to commit something
> >>that I wrote but don't want to use in my code *at this moment*: I
> >>commit the patch with an appropriate log message, then I roll it back
> >>right away.
> >
> >That may be a use case, but it doesn't seem like a terribly good one.
> >"svn cp . branch-url" is the preferred way of recording changes
> >without
> >corrupting the mainline.
>
> Fair enough. But I still think that the "I screwed up my last commit
> and want to revert it" use case stands.

Indeed, the "revert revision N" is definitely a valid use case (my
personal count is at twice this week, which IMHO is on the high side).
However, it occurs much less often than the "merge revision N for
backport" use case (I'm at four or five this week, which is fairly
typical), so while valid, it's not necessarily compelling enough to
warrant a redundant-though-slightly-quicker option for the
command-line client, even one with as small a footprint as the style
suggested by Fitz.

-- 
Daniel Rall

  • application/pgp-signature attachment: stored
Received on Sat Jan 14 00:30:03 2006

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.