On Jan 19, 2005, at 1:42 PM, Greg Stein wrote:
>
> Same. I can *easily* see a time when we could 'svn co' from any old
> DAV server. In fact, the original code *could* do that, but we moved
> to a report for performance purposes (lack of HTTP pipelining). When
> we get a pipelining library, then I fully expect that we could switch
> back to a series of PROPFIND/GET requests to do the checkout.
Ahem. :-)
That's just not true. From the very beginning, ra_dav was *always*
sending a custom REPORT to describe a working-copy's local revisions to
the server. The response was tree without file content; ra_dav then
parsed the response and did many GET and PROPFIND requests to fetch
content. So no, it never worked against a generic DAV server. Not
then, not now.
And that's just the tip of the iceberg. Pretend that a generic DeltaV
server came into existence, and we decided to spend significant energy
rewriting ra_dav to interoperate with it.
* How do we describe working-copy revisions to the server during
update, without a custom REPORT? By building an activity with
verison-resources in it? But ghudson just got *rid* of that burden.
* How do we map svn's concepts of history to DeltaV history concepts?
- we use a custom REPORT to fetch logs.
- we use a custom REPORT to fetch a path's various locations over
time, so that our subcommands can follow renames efficiently.
* How will we efficiently fetch fulltexts for 'svn blame' without a
custom REPORT?
* How do we convert a date into a revnum without a custom REPORT?
* How about svn's concepts of unversioned revision properties?
- There's no such concept in DeltaV.
- At the moment, we're doing an auto-checkout of a baseline
resource so we can PROPPATCH it. That's a major violation of DeltaV,
since a baseline is a VR, not a VCR.
I'm sure there are other things I'm forgetting here.
In other words, I feel like you guys are wearing rose-colored glasses.
We've never had a generic DeltaV client, not even *close*. And I'm not
even persuaded we *could* convert ra_dav into such a beast, because svn
concepts don't really line up with DeltaV. I know that you guys really
want to finish serf and get pipelining into ra_dav. But that brings us
only microscopically closer to the goal.
These days, cmpilato and I have realistically given up on the goal.
The tremendous effort required to achieve it -- coupled with the fact
that no deltaV server even exists -- has led us to only care about the
opposite problem. Autoversioning provides real and tangible benefits.
It's only going to become a bigger deal when it's "finished" in svn
1.2. People are dying to use DAV clients against svn repositories,
because the clients already exist. And because DAV has no versioning
concepts, it's easy for mod_dav_svn to have a double-life: custom svn
server, and dumbed-down file server for DAV clients. There's no
contradiction there, no problems with semantic mapping.
So one more custom REPORT seems like a drop in the ocean to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 21:18:01 2005