RE: Difference between merge -c and merge -r
From: Scott Bloom <scott_at_towel42.com>
Date: Fri, 29 Sep 2017 16:02:04 +0000
That does clarify things. I would suggest something in the docs (tool help as well as the redbook), since the redbook uses both with no reason for either.
My coworker, read somewhere it was "cherry picking", I have always used -r when I need to do it, and yes -r 99:100 is "harder" than -c 100..
But we were getting some conflicts, and I wasn't sure of the cause.. when speaking with the coworker as to how he was merging, this came up.
Thanks for the detailed explanation.
On Fri, Sep 29, 2017 at 03:36:27PM +0000, Scott Bloom wrote:
The -c option is just syntactic sugar.
Before it was invented, merging a single revision, say r100, was always done like this: svn merge -r99:100 This asks svn to merge the difference between r99 and r100, i.e.
With -c, we can write this in a shorter way: svn merge -c100 This is equivalent to svn merge -r99:100
The -r option also supports "reverse" merges, where the differences of the original changeset are reversed: svn merge -r100:99 effectively backs out changes from r100. To achieve this effect with -c, prepend a minus sign to the number: svn merge -c-100
To make copy-pasting revision numbers from the output of 'svn log' easier the -c option also accepts numbers with 'r' prepended:
To an untrained eye the -c-r100 case might look as if the -r option was used, but that is not the case. It's the -c option with a minus for a reverse-merge and an 'r' prepended to the revision number.
The -c option also accepts multiple revision numbers separated by commas:
I hope this clarifies the situation :)
This is an archived mail posted to the Subversion Users mailing list.