On Wed, Oct 1, 2008 at 10:53 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Wed, Oct 1, 2008 at 9:37 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Wed, Oct 1, 2008 at 10:31 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> Ben Collins-Sussman wrote:
>>>> On Tue, Sep 30, 2008 at 7:27 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>>>> Mark Phippard wrote:
>>>>>> Hey, couldn't we ditch wc-props too? I imagine/hope the new WC would
>>>>>> do this too though. As I said, I think this is a great idea and even
>>>>>> overdue.
>>>>> wc-props are optional -- we could ditch them today.
>>>>
>>>> ...at the cost of making ra_neon even slower. :-)
>>>
>>> Not if we simply dispense with this nonsense of treating the !svn URLs as
>>> opaque and mysterious.
>>>
>>> And another easy-win speedup would be for our DAV clients to stop using 12
>>> PROPFINDS to do simple URL negotation -- we could have long ago written a
>>> custom REPORT to answer those kinds of questions in a single turnaround.
>>
>> Do we even need to do this URL negotiation? Couldn't we just switch
>> to making assumptions about the URL's and dispense with all of this?
>>
>> If we have to continue to maintain mod_dav_svn anyway for older client
>> support, would it make sense to just add new features into current
>> library? Such as custom REPORT requests etc? Does the fact that the
>> current library is related to DAV block us from doing any of the
>> things you want to do?
>
> Is it theoretically possible to move in this direction? Sure.
> mod_dav_svn is currently a strange mix of baroque DeltaV formalities
> and custom svn REPORT requests. We could just 'evolve' mod_dav_svn to
> drop more and more of the DeltaV formalities, until it basically
> becomes nothing but a big heap of custom REPORT exchanges. But I
> argue that this will make mod_dav_svn even harder to read and
> maintain. While ra_neon / ra_serf might be able to simplify their
> chattiness, mod_dav_svn just keeps growing in complexity, getting more
> and more special cases heaped on, and still all going through
> mod_dav's vision of the universe. It contradicts the goal of making
> an HTTP layer which is easily readable and maintainable.
Agreed. But mod_dav_svn is not going away. Maybe we do not add new
features to it, but we have to maintain it. So the code has to live
on and cannot really even be cleaned up. Does putting new code in a
new library make that much difference? Can't the new code just live
in new .c files and be built into the same library for deployment? I
have two goals in suggesting this option:
1) Eliminate the need for 2 URL's. This is bad. With your Google
code hosting do you really want to offer 2 URL's for all repositories?
I am sure we do not want to do that at CollabNet and I doubt
SourceForge and other sites want to either.
2) We do not have do a new implementation of DAV autoversioning.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 16:57:35 CEST