On 25 Oct 2005 14:07:08 -0500, email@example.com <firstname.lastname@example.org> wrote:
> Alan Barrett <email@example.com> writes:
> > On Tue, 25 Oct 2005, C. Michael Pilato wrote:
> > > Why, again, was it considered more desirable to introduce -c than to
> > > simply start allowing -rM to mean -rM-1:M ?
> > That would break the existing meaning of "svn diff -r N".
> > Perhaps some other syntax could be defined, while still using "-r"
> > instead of adding "-c"? For example, "svn diff -r :999" is easy enough
> > to type, and could be defined to mean the same as "svn diff -r 998:999".
> Yes, +1. (Sorry, I forgot about the current diff syntaces.)
> I'd really like to not use up a single letter option, especially when
> the meaning is so close to an existing option. If we can get there by
> twiddling the syntax of the optarg instead, that'd be great.
When I see syntax like :N or N:, I would assume it refers to (0:N, N:HEAD).
The -rN syntax is equally ambiguous. See
The "-c" or "--change" option is much more clear. Using the "-c"
option, you can easily cherrypick changes from trunk to merge to a
branch. Here's an example use case, from the STATUS file for 1.3.x.
* r16930, r16975, r16989, r16990.
Actually fix the cause of perl bindings segfault by allocating for
... (yada yada yada)
To merge these four changes, I can type
svn merge -c16930 ../trunk .
svn merge -c16975 ../trunk .
svn merge -c16989 ../trunk .
svn merge -c16990 ../trunk .
In future, I'd like to see the "-c" syntax extended, so that you can
merge multiple revisions. Then you could just type:
svn merge -c16930,16975,16989,16990 ../trunk
David James -- http://www.cs.toronto.edu/~james
Received on Tue Oct 25 22:58:09 2005