C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> C. Michael Pilato wrote:
>>> Hyrum K. Wright wrote:
>>>> C. Michael Pilato wrote:
>>>>> Julian Foad wrote:
>>>>>> The fact that a "^/" prefix was the way to recognise an incoming
>>>>>> relative URL on the command line doesn't mean it has to be the way it
>>>>>> is communicated internally later on. We could use a different way to
>>>>>> distinguish the type of target, such as attaching an enumeration {
>>>>>> TARGET_TYPE_URL, TARGET_TYPE_REL_URL, TARGET_TYPE_PATH }.
>>>>> In the past I've wanted to make the svn_opt target-parsing stuff get
>>>>> transformed to return not arrays of 'const char *' but arrays of
>>>>> svn_opt_target_t (or some new structure for holding parsed target-y
>>>>> stuff). At the time I wanted to do this because I wanted the
>>>>> following
>>>>> fields:
>>>>>
>>>>> const char *path;
>>>>> svn_opt_revision_t peg_revision;
>>>>>
>>>>> So if you go this route of return structures with paths and path-type
>>>>> enums, consider also plopping the peg_revisions in there, too.
>>>> We may also want to put the operative revision in there, too.
>>> Ehh ... operative revisions are bound to a particular path, so I'm not
>>> sure this is such a good idea.
>>
>> Sorry, I wasn't specific enough with my antecedent. I meant that the
>> svn_opt_target_t thingy could be:
>>
>> const char *path;
>> svn_opt_revision_t peg_revision;
>> svn_opt_revision_t operative_revision;
>>
>> That would bind the operative revisions to paths, would it not?
>
> Oh, I know what you meant. The mistake was mine, as I meant to say,
> "... operative revisions *aren't* bound to a particular path". That
> might not be much more clear than the mistaken form, so read on.
>
> A function whose task is to parse command-line arguments into these
> path-y thingamajigs cannot possibly fill in the operative_revision bit.
> The -r and -c flags are position independent in the command-line; their
> interpretations rely entirely upon the specific subcommand in use. No
> generic path-parsing API function can assign operative revisions based
> solely on the input of an array of target strings.
Unless the operative revision is the same as the peg revision, in which
case, it would be useful to assign them both.
> Now, that might be fine. It might be that we have the structure member
> there and the path-parsing API promises to set operative_revision->kind
> to svn_opt_revision_unspecified (or maybe to _head for URLs and _base
> otherwise), atop which the individual subcommands can choose to store
> real operative revisions as determined by examining
> opt_state->revision_ranges / ->start_revision / ->end_revision.
That sounds reasonable. The only point I was making was that an api may
want to accept targets of separate operative revisions, and extending
this type of structure seems like a valid place to put that information.
Sure, there may be duplicate revision information when all the targets
have the same operative revision, but such overhead is negligible.
Plus, the completeness just gives me warm fuzzies inside.
-Hyrum
Received on 2008-03-07 04:33:06 CET