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.
> If we ever get a highly-intelligent merge algorithm which supports
> convergence, this kind of "commit and then immediately revert"
> operation
> may confuse it. One of the problems intelligent merge operations have
> is trying to figure out why you reverted a change: did you just not
> want
> the change *yet*, or did you not want it *at all*? So it can have
> trouble figuring out what to do with the graph:
>
> A --> B --> A
> --> B
>
> If you reverted B in the first line because you didn't want the change
> yet, then you want the result to be B. If you reverted it because you
> decided the change was a bad idea, then you want the result to be A.
Hm. I wonder what p4 and clearcase do in this situation... anyone?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 13 23:31:08 2006