On Thu, 31 May 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > On Thu, 31 May 2007, hwright@tigris.org wrote:
> > ...
> >> When searching for child mergeinfo, look for proper children of the given path,
> >> not just paths with a common prefix. Followup to r25138.
> > ...
> >> * subversion/libsvn_fs_util/mergeinfo-sqlite-index.c
> >> (get_mergeinfo_for_children): Select only paths which are proper children of
> >> the requested path.
> > ...
> >> --- trunk/subversion/libsvn_fs_util/mergeinfo-sqlite-index.c (original)
> >> +++ trunk/subversion/libsvn_fs_util/mergeinfo-sqlite-index.c Thu May 31 07:50:12 2007
> >> @@ -619,7 +619,7 @@
> >> "WHERE path LIKE ? AND revision <= ?;",
> >> -1, &stmt, NULL), db);
> >>
> >> - like_path = apr_psprintf(pool, "%s%%", path);
> >> + like_path = apr_psprintf(pool, "%s/%%", path);
> >>
> >> SQLITE_ERR(sqlite3_bind_text(stmt, 1, like_path, -1, SQLITE_TRANSIENT), db);
> >> SQLITE_ERR(sqlite3_bind_int64(stmt, 2, rev), db);
> > ...
> >
> > Looks good, Hyrum. Is our test case exercising this yet? (I think it
> > should, to prevent regression.)
>
> Not directly, but the merge sensitive log functionality depends on this
> function, so the test(s) are hitting this function indirectly. Do we
> have a simple way to directly test this function?
I should've been more clear -- I intended to refer to filtering of
"/tags/1.1.0.1" when the path we're trying to get merge info for is
"/tags/1.1.0" (which you fixed with the addition of the "/" character
in value inserted into the "path LIKE ?" clause).
- application/pgp-signature attachment: stored
Received on Thu May 31 22:36:50 2007