On Wed, Nov 17, 2010 at 5:45 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Hi Paul.
>
> On Wed, 2010-11-17, pburba_at_apache.org 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
>
>
>
>
Received on 2010-11-17 16:13:42 CET