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?
-Hyrum
Received on 2008-03-07 04:13:17 CET