Paul Burba wrote:
> Regarding Issue# 2818: "Provide a 'merge' API which allows for merging
> of arbitrary revision range"
> I've got the API change portion about ready to go and want to get some
> agreement on what the CL UI would look like (this will partially support
> the MT cherry picking requirement
> I think dlr's initial off the cuff suggestion in the initial issue
> description, support both multiple ranges/revision ranges for both -c
> and -r using a comma separated list, is the right way to go, e.g.:
> svn merge -c 4,-6,8,9,10,11,12,-20,-21,-22
> svn merge -r 3:4,6:5,7:12,22:19
> IMHO supporting the use of both -r and -c at the same time would also be
> nice since it allows a user to cherry pick changesets in the most
> concise way...
> svn merge -c4,-6 -r7:12,22:19
> ...but I'm not going to fight to hard for that if folks don't like it.
> The work I've already done compacts these ranges into their minimum
> representation, so no need to worry about overlapping ranges, or ranges
> that fully or partially cancel each other out -- If a user really wants
> to merge -r5:7,7:5 we'll let them, but we'll be smart enough to not
> actually do anything.
> Any thoughts, alternate suggestions, and/or objections are appreciated.
I like the idea of being able to specify multiple ranges on the
command-line. I just wonder if we shouldn't adhere to previously
established conventions that allow for multiple instances of the same option
rather than add a new comma-delimited syntax:
svn merge -c4 -c8 -c9 -c10
I have no strong opinions on the matter, though.
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Sep 26 20:52:46 2007