On 2012-03-28, Greg Stein wrote: On Mar 28, 2012 4:16 AM, "Julian Foad" <julianf...@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
