[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r945280 - in /subversion/trunk: build.conf subversion/libsvn_ra_serf/commit.c subversion/mod_dav_svn/dav_svn.h subversion/mod_dav_svn/posts/ subversion/mod_dav_svn/posts/create-transaction.c subversion/mod_dav_svn/repos.c

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 17 May 2010 15:23:03 -0400

On Mon, May 17, 2010 at 15:05, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>...
>> This doesn't match the "int" return type you've defined, and it
>> results in build errors (see the buildbots).
>
> Hrm.  This from util.c:
>
> int
> dav_svn__error_response_tag(request_rec *r,
>                            dav_error *err)
> {
>   ...

Oh. Hmm. Thought it was that, but I don't have the code checked out
yet, nor the line numbers to align.

> I'll look into this (and the other similarly unexplainable) return mismatch
> you mentioned.

Cool.

Seems that it is just the windows compiler being strict, but that is a
Good Thing!! :-)

On your dev checkout, gcc should have lots of flags/warnings, so it
may pop right out at you.

>> Can I say again that I hate XML, and am very much -0.5 on using it in
>> our protocol like this? These bodies have nothing to conform to, so
>> there is no reason to use XML. If you're doing it for *expedience*
>> rather than *propriety*, then I'd suggest taking short cuts now could
>> hurt us in the long term. XML means we need to deal with escaping as
>> we move forward. It is overly wordy. Hard to write parsing code. etc
>> etc.
>
> I have a local patch here that adds a mod_dav_svn utility function for
> stringbuf'ing a request into a giant block of memory and parsing into a
> skel.  I can certainly switch to that approach if you feel that strongly
> about it.  Would you be okay with a documented requirement that these new
> POSTs use "text/plain", skel input, where the first atom of the skel is the
> POST operation verb ("create-transaction", "lock-paths", etc.)?

Much more preferable!

And note that skels are application/octet-stream since they can encode
binary data (one the ways it will be easier to support!).

Cheers,
-g
Received on 2010-05-17 21:23:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.