Greg Stein wrote:
> On Fri, Nov 14, 2008 at 9:55 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> ...
>> You cannot relax this constraint while maintaining the promises
>> of the API.
>
> Fine.
>
> We'll rev it then. It *needs* to be rev'd anyways. It has "hex digest"
> parameters in there, rather than svn_checksum_t values. It already
> needs a rev, but that isn't an API that I wanted to touch in 1.6.
>
> I'd also want to clarify the pools in that API. It is simply too
> confusing when looking at them: is a pool argument intended for baton
> allocation, or for scratch usage? Or both? The docs are not clear on
> what the pool arg is intended for, nor what its lifetime is guaranteed
> to be.
>
> We can take a whack on the editor ordering constraints, and loosen
> any/all of them. Clarify the notion of postfix textdeltas. Enable
> props and textdeltas to be done at postfix time (tho: I think we
> *should* usually have all the props at open_file time as a result of a
> PROPFIND Depth:1 on the parent directory).
>
> So. API will be rev'd.
+1. Awesome. (And I agree with all of your criticisms above.)
> Is there any other blocking issue to tossing Neon?
As noted elsewhere, we need parity with Neon in its supported auth types (at
least those that Subversion takes advantage of), and with proxy support
levels. I'll let others more familiar with the situation add to this list
as needed (though I would strongly encourage said list to become tracker
issues ASAP).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-14 19:12:38 CET