epg_at_google.com wrote:
> Thanks for looking into this.
>
> Lieven Govaerts <svnlgo_at_mobsol.be> writes:
>
>> I've tested get_file_dir over ra_serf, and found that - unlike svnserve
>> - mod_dav_svn doesn't care if you're asking directory information
>> (PROPFIND allprop Depth:1) on a file. Which means that ra_serf doesn't
>> know anything was wrong.
>
> I can understand some people want to support things like this for
> compatibility for MICROS~1 Web folders or whatever. But we
> mustn't allow such side features to compromise svn itself.
>
>> Now we can correct this by adding an extra check to see of the directory
>> is really a directory. AFAIC the extra cost of the PROPFIND request to
>> the server is not worth it. Also, there's a nice workaround: if you
>> don't know if you're handling a file or a directory, use svn_ra_check_path.
>
> Extra round trips are no good, whether above or below the svn_ra
> hood.
> Right now, I'm issuing get_files with stupid code to try to figure out if it was a directory
I'm missing something here. You're asking an API to do something that
it's not meant for, expecting to get an error which clearly doesn't make
sense either? Why don't you use the correct API instead?
> and we're using neon; for
> serf, which proceeds to write some HTML error garbage into my
> file,
>
Well, the fact that ra_serf dumps the XML output is not correct either.
If that error comes from the server, I'd at least expect the same result
as you get for ra_neon now. Fixed in r31374.
> well, I just have to declare serf unsupported.
Sorry, no, can't have that :)
Lieven
---------------------------------------------------------------------
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-22 22:55:06 CEST