On Wed, Nov 17, 2010 at 5:45 AM, Julian Foad <[email protected]> wrote: > Hi Paul. > > On Wed, 2010-11-17, [email protected] wrote: >> Log: >> Reintegrate the issue-3668-3669 branch. > > If you could insert a summary of this change here in the log message, > that would be helpful.
Sure thing, I added a bit more explanation to the log message. FWIW I always figured the log messages of the feature branch served this purpose, but your implied point is certainly valid, it is a lot more convenient for everybody other than the branch author(s)! For your convenience, here is the new log message: [[[ Reintegrate the issue-3668-3669 branch. This fixes issue #3668 'inheritance can result in self-referential mergeinfo' and issue #3669 'inheritance can result in mergeinfo describing nonexistent sources'. The work for both of these issues was done in tandem for two reasons: First, because they are very similar, i.e. both are variations of the problem where merge tracking's simple inheritance model resulted in mergeinfo that contained invalid path-revs (either self-referential or simply non-existent). Second, the fix for issue #3668, while simple, behaves badly in cases where it is corrected but issue #3669 in not, see http://subversion.tigris.org/issues/show_bug.cgi?id=3668#desc5 The core of the issue #3669 fix is two-fold: First, rev svn_ra_get_mergeinfo() so it can request that the server validate any inherited mergeinfo it returns and second, rev svn_repos_fs_get_mergeinfo() so the server can actually perform this validation. Note that since an RA API was revved, a lot of the noise in this change is simply updating the plumbing of the various RA providers. Any potential reviewers wanting to see the heart of this change should probably start here: libsvn_fs/fs-loader.c:svn_fs_validate_mergeinfo(): Does the heavy lifting of validating mergeinfo. libsvn_client/merge.c:get_invalid_inherited_mergeinfo(): Indirectly uses the new RA API to determine what portion of WC path's inherited mergeinfo is invalid. ]]] let me know if that's not what you had in mind. > I see it's ... rather large. As I mentioned in the new log, a lot of the code churn is RA plumbing changes...hmmm, I guess this is exhibit 'A' as to why a more thorough log message is helpful! Thanks, Paul >> Modified: >> subversion/trunk/ (props changed) >> subversion/trunk/subversion/include/private/svn_dav_protocol.h >> subversion/trunk/subversion/include/svn_fs.h >> subversion/trunk/subversion/include/svn_ra.h >> subversion/trunk/subversion/include/svn_repos.h >> subversion/trunk/subversion/libsvn_client/copy.c >> subversion/trunk/subversion/libsvn_client/merge.c >> subversion/trunk/subversion/libsvn_client/mergeinfo.c >> subversion/trunk/subversion/libsvn_client/mergeinfo.h >> subversion/trunk/subversion/libsvn_fs/fs-loader.c >> subversion/trunk/subversion/libsvn_fs/fs-loader.h >> subversion/trunk/subversion/libsvn_fs_base/tree.c >> subversion/trunk/subversion/libsvn_fs_fs/tree.c >> subversion/trunk/subversion/libsvn_ra/deprecated.c >> subversion/trunk/subversion/libsvn_ra/ra_loader.c >> subversion/trunk/subversion/libsvn_ra/ra_loader.h >> subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c >> subversion/trunk/subversion/libsvn_ra_neon/mergeinfo.c >> subversion/trunk/subversion/libsvn_ra_neon/options.c >> subversion/trunk/subversion/libsvn_ra_neon/ra_neon.h >> subversion/trunk/subversion/libsvn_ra_serf/mergeinfo.c >> subversion/trunk/subversion/libsvn_ra_serf/options.c >> subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h >> subversion/trunk/subversion/libsvn_ra_svn/client.c >> subversion/trunk/subversion/libsvn_repos/fs-wrap.c >> subversion/trunk/subversion/mod_dav_svn/reports/mergeinfo.c >> subversion/trunk/subversion/svnserve/serve.c >> subversion/trunk/subversion/tests/cmdline/merge_reintegrate_tests.py >> subversion/trunk/subversion/tests/cmdline/merge_tests.py > > > >
