I'll first list the options suggested (that I've noticed) so I
can refer to them.
1) Add --reverse to pair with -c N.
2) Use negative revisions with -c, like '-c -123'.
3) Add new option, such as -C/--rchange.
On 2006-1-17 Greg Hudson <ghudson@MIT.EDU> wrote:
> On Tue, 2006-01-17 at 14:23 +0100, Molle Bestefich wrote:
> > The question about how to roll back a revision comes up at least once
> > a month (or so) over on the tsvn lists. (Which of course immediately
> > results in someone pointing to the 'revert revision' menu option and
> > the OP feeling stupid.. hee hee :-)).
>
> Once a month isn't terribly often. But there's a deeper question here
> than the frequency of user rollback operations.
I agree that it isn't used often, but it is not altogether rare.
It gets more common with a "stable trunk" model and lots of
committers.
> The forward -c option is both a convenience for common operations ("show
> me what changed in revision N", "merge the change made in revision N")
> and also a road towards a more precise command set, where we can talk
> about revisions either as changes or as states.
>
> A reverse -c option is simply a convenience for an operation which may
> be common ("roll back the change made in revision N"). It allows the
> command set to talk about inverse-revisions as changes, but in my
> opinion that's just muddying the waters.
I think about it the other way: *not* having a reverse -c option
is basically an incomplete implementation of the "change"
concept.
Having (forward) -c is more important as you say, but since (I
assume) it will become the preferred syntax, I think it would
make sense if the reverse operation was similar.
That said, using -r100:99 to back out a change isn't all *that*
different from using -c100 to put it in. It isn't like other
systems that use an entirely different *concept* to back out a
change vs. putting it in. So I don't want to overstate the
utility of the reverse -c idea.
> The argument has been made that "svn merge -c -N etc." is more intuitive
> than "svn merge -r N:N-1 etc.", and will result in fewer user questions
> asking how to roll back a change. I have great doubts; I think roughly
> the same class of users will need to be taught how to roll back changes
> either way.
>
> As I originally said, I'm only -0 on this concept, not -1. I think it's
> adding complexity to the command syntax for insufficient gain, but not
> so much that I'm going to haul out a veto.
Schemes (2) and (3) should not add any significant complexity or
maintenance burden unless I'm missing something. (I tried a
negative arg to -c and it just gave me a warning that negative
revisions were not valid-- it didn't try to parse -123 as an
option or anything.)
Even though I wrote a patch for scheme (1), I don't think it is
the way to go (nor was it my original idea, I was just trying to
help get the party started). It is unlikely --reverse will be
used for anything else besides -c, so it would pretty much be a
syntax wart.
-- bart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 18 03:28:22 2006