C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>>A couple of months ago, there was a short discussion about supporting
>>the --targets option more fully.  Julian Foad wrote a proposal
>>regarding how to better handle the --targets option, and I promptly
>>disappeared from the discussion. :)
>>I've started to do some investigation of my own, and I currently have an
>>improved version of the patch I sent in the previous discussion. I do
>>have the following questions:
>>1) Currently, if multiple --targets options are given, we silently
>>ignores all but the last one. In such a case, should be process each
>>one, or simply throw and error?
> My vote: process them each/all, additively.
>>2) In order to have --targets be used to specify only repeatable
>>targets, would it be favorable to prepend the list of targets it
>>generates, rather than append them? In most of the commands I've looked
>>at, the "special" command arguments are last, so prepending would
>>maintain the correct meaning of arguments given by their order. Should
>>such prepending be done for each command individually, or across the board?
> You're making a false assumption here:
> svn update foo bar --targets /path/to/more/targets
> is *exactly* the same thing as:
> svn update --targets /path/to/more/targets foo bar
This wasn't very clear. Your false assumption is that option positioning
with respect to command arguments matters. The reality is that it doesn't.
Sorry for the confusion.
> Our option space is global, and option positioning doesn't matter. Options
> are stripped first, leaving command arguments. As with most things, I'd say
> consistency is best -- either always prepend, or always append, and make the
> documentation say clearly which you do.
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed May 31 21:20:20 2006