Lieven Govaerts <svnlgo_at_mobsol.be> writes:
> 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?
Calling opendir(3) on a plain file is using "the correct API".
So is calling svn_ra_get_file on a directory. Try-and-fail is
better than test-first, but I'm not going to argue that here.
So, here is what I'm doing:
- I have a path which may be a file or a directory
- I need to get its properties and contents if it's a file, or
just its properties if it's a dir
- Most paths are files
=> try:
svn.ra.get_file(...)
except NOT_FILE:
svn.ra.get_dir(2(...)
It's just more complicated than it needs to be because I also
have to support DAV.
That's the story of my life right there: "It's harder than it
should be because of DAV."
So, in most cases (files), I issue one get_file and am done; in
the (rare) case of a modified directory, I issue two requests:
get_file and get_dir2. Issuing a check_path on every single path
just to find this rare case would be stupid[1].
> > 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 :)
Well, that's where we (gvn) are for other reasons anyway, as
we've discussed on IRC.
[1] Note that svn does this all the time, sigh. Check out what
we do for 'svn cat':
get-latest-rev
reparent /welcome
check-path /welcome_at_119767
get-file /welcome r119767 props
get-file /welcome r119767 text
All I should see in the log for svn cat is this:
get-file /welcome r119767 text props
Sure, svn cat, who cares? I wonder how many other places we
have crazy things like this...
---------------------------------------------------------------------
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 23:16:42 CEST