You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2012/05/14 12:13:47 UTC

Re: buildbot failure in ASF Buildbot on svn-slik-w2k3-x64-ra

On 2012-03-28, Greg Stein wrote:
On Mar 28, 2012 4:16 AM, "Julian Foad" <ju...@btopenworld.com> wrote:
>> Greg Stein wrote:
>>
>> > I believe that r1306111 fixes this.
>> >
>> > Note that the changes in this area have exposed a long-standing bug in
>> > the svn client's get_dir handling. I've left behind some docco to
>> > guard future readers/developers.
>>
>> Hi Greg.  Just a docco tweak:
>>
>> Index: subversion/svnserve/serve.c
>> ===================================================================
>> --- subversion/svnserve/serve.c    (revision 1306195)
>> +++ subversion/svnserve/serve.c    (working copy)
>> @@ -1565,7 +1565,9 @@ static svn_error_t *get_dir(svn_ra_svn_c
>>            /* The fields in the entry tuple.  */
>>            svn_node_kind_t entry_kind = svn_node_none;
>>            svn_filesize_t entry_size = 0;
>>            svn_boolean_t has_props = FALSE;
>> +          /* If 'created rev' was not requested, send 0.  We can't use
>> +           * SVN_INVALID_REVNUM as the tuple field is not optional. */
>> +          svn_revnum_t created_rev = 0;
>> -          svn_revnum_t created_rev = 0; /* ### SVN_INVALID_REVNUM  */
>>            const char *cdate = NULL;
>>            const char *last_author = NULL;
>>
>> Does that correctly capture the point there?
> 
> That captures the actual, but I'm really not sure of the overall
> intended semantics here. It appears the client can *optionally*
> request the rev. (the whole DIRENT_FIELDS thing in serve.c) ... in
> that case, what should be sent? We send 0, cuz as you note, INVALID
> breaks things. Nothing should be sent, or maybe INVALID. But it's
> inconsistent.  Messy.
> 
> The svn protocol starts to fall outside my interest boundary. Tests
> were failing, so I fixed it. But I don't like svnserve. I'll let
> you/others debate the proper behavior here.

I committed that comment, w3ith a reference to this email thread, in r1338131.

- Julian