epg_at_google.com wrote on 05/22/2008 04:16:12 PM:
> 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...
This reminds me, I was using an http debug proxy and noticed svn repeated
the same three http requests 3 times in a row for "svn ls". (Didn't check
other commands yet.)
Same binary data in, same binary answer.
For a directory listing:
1 PROPFIND <path> props(version-controlled-configuration
baseline-relative-path
repository-uuid)
2 PROPFIND [version-controlled-configuration] props(checked-in)
3 PROPFIND [checked-in] props(baseline-collection
version-name)
4 *** Repeat 1 *** PROPFIND <path>
props(version-controlled-configuration
baseline-relative-path
repository-uuid)
5 *** Repeat 2 *** PROPFIND [version-controlled-configuration]
props(checked-in)
6 *** Repeat 3 *** PROPFIND [checked-in] props(baseline-collection
version-name)
7 *** Repeat 1 *** PROPFIND <path>
props(version-controlled-configuration
baseline-relative-path
repository-uuid)
8 *** Repeat 2 *** PROPFIND [version-controlled-configuration]
props(checked-in)
9 *** Repeat 3 *** PROPFIND [checked-in] props(baseline-collection
version-name)
10 *** Repeat 1 *** PROPFIND <path>
props(version-controlled-configuration
baseline-relative-path
repository-uuid)
11 *** Repeat 2 *** PROPFIND [version-controlled-configuration]
props(checked-in)
12 PROPFIND [baseline-collection] props(allprop)
13 *** Repeat 1 *** PROPFIND <path>
props(version-controlled-configuration
baseline-relative-path
repository-uuid)
14 *** Repeat 2 *** PROPFIND [version-controlled-configuration]
props(checked-in)
15 PROPFIND [baseline-collection] props(deadprop-count)
16 PROPFIND [baseline-collection] props(resourcetype)
17 if recursive repeat 13-16 for each directory
On a slow connection (say 400ms ping time, this might add a few seconds
to each conversation)
Haven't had time to look into it any more, and it might just be a neon
issue anyway... (This was with 1.4.6, but I'm pretty sure 1.5 rc5 with
a newer neon was the same)
Kevin R.
---------------------------------------------------------------------
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-23 15:36:05 CEST