I come back from lunch, and Philip has spotted the bug.
You know, I've lost track of how many times that has happened :-).
Thanks, Philip; I'll check in a fix.
-K
Philip Martin <philip@codematters.co.uk> writes:
> This condition...
>
> > {
> > svn_fs_root_t *newroot;
> > changed_paths = apr_hash_make (subpool);
> > SVN_ERR (svn_fs_revision_root (&newroot, fs, this_rev, subpool));
> > SVN_ERR (detect_changed (changed_paths, newroot, subpool));
> > }
> >
> > SVN_ERR ((*receiver) (receiver_baton,
> > (discover_changed_paths ? changed_paths : NULL),
>
> ... is different from this condition.
>
> > this_rev,
> > author ? author->data : NULL,
> > date ? date->data : NULL,
> > message ? message->data : NULL,
> > subpool));
> >
> >
> > (It's using a subpool because it's looping over log messages, of
> > course.)
> >
> > And that's all I know right now; don't know yet why/how changed_paths
> > is screwed up. Working on it.
>
> changed_paths gets initialised to NULL outside the loop. If this_rev
> is zero on any iteration other than the first then changed_paths will
> be rubbish.
>
> --
> Philip Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 7 21:25:45 2003