>
> Actually, I'm not so sure about that. ra_dav usually asks for
> specific properties. I don't think it asks for <allprops> very often
> at all. You should check the code; it may in fact be perfectly safe
> to remove DeltaV props from an <allprop> response.
When I removed "Checked-in" svn ls failed saying it expected to find
the Checked-in prop. But now that you are casting doubt in my mind,
I'll have to try it again. But if in fact we don't need it, then I do
agree that this would be a better solution.
>
> > 2. If we make the clients query for the has_props, then we would need
> > to handle the case of the older server. This is fixable. If we get a
> > 404 for that property, then we do an allprop and request everything -
> > using the old way to determine has_props. This would be much slower,
> > but not break any existing functionality.
>
> That's one solution. But then it means doing two PROPFIND requests
> instead of one, when talking to older servers. It reeks of evil:
> "Subversion 1.3 now runs 'svn ls' twice as fast, but it's even
> *slower* when you point it to a pre-1.3 server!"
>
> There may be more clever solutions. Like, for example, in the
> PROPFINDs for vcc, baseline, etc. which lead up to the "final"
> PROPFIND, we could add the 'has_props' to our list of props to
> fetch. Then we'd know -- early on -- if 'has_props' is supported or
> not. Then the final PROPFIND can either be a target list, or an
> <allprop>.
Agreed - Two propfinds on huge collections would take a while indeed.
I like your solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 22 21:19:23 2005