Re: [PATCH] Repository root relative url support in svn CLI -- REDUX

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.

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.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand