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.
Cheers,
-g
Received on 2012-03-28 11:22:27 CEST