On 2012-03-28, Greg Stein wrote:
On Mar 28, 2012 4:16 AM, "Julian Foad" <julianfoad_at_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.
Received on 2012-05-14 12:14:23 CEST