Troy Curtis Jr wrote:
> It turns out this simplistic approach doesn't work. Surprising, no?
>
> My proposal hinged on the assumption that all the downstream functions
> handle peg revision and so we can just stick an empty peg revision on
> any target that doesn't already have one. But of course this isn't
> true of commands expecting only paths and I suspect now that I think
> of it there may be cases where peg revs aren't actually handled for
> certain url cases either.
It sounds to me like what's broken is the idea that we can validly stick the
"@PEG" back on to a path or URL again after parsing and canonicalising it.
Do you think we can get rid of all the code that relies on that, and deprecate
the functions that do it and any functions that currently take "<canonical path
or URL>@PEG" as input? Once we've parsed the syntax, keep the results separate.
That sounds like the Right Thing. (The alternative, if we insist on glueing the
two parts back together, is to define how we're going to do it in a way that
doesn't lose information.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-28 10:28:00 CEST