Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MergeCodeImprovements" page has been changed by JulianFoad: http://wiki.apache.org/subversion/MergeCodeImprovements?action=diff&rev1=1&rev2=2 Comment: Split double-underscores to prevent the Wiki interpreting them as mark-up. === Use svn_client__pathrev_t more widely === - A particular concern is where a URL and a rev are currently being gathered, that at first glance should be the URL and rev of the same location, but on closer inspection may not be. For example, at the beginning of filter_self_referential_mergeinfo() there are calls to svn_client_url_from_path2() and svn_wc__node_get_base_rev(), but while the latter is clearly asking about the WC "base" version, the former is not, and may return a URL different from the base URL if the node is locally copied/added/etc. + A particular concern is where a URL and a rev are currently being gathered, that at first glance should be the URL and rev of the same location, but on closer inspection may not be. For example, at the beginning of filter_self_referential_mergeinfo() there are calls to svn_client_url_from_path2() and svn_wc_``_node_get_base_rev(), but while the latter is clearly asking about the WC "base" version, the former is not, and may return a URL different from the base URL if the node is locally copied/added/etc. - Here's an example of how useful working with path-revs can be, beyond mere notational convenience. I thought I saw (but can't find it at the moment) a call to svn_mergeinfo__get_range_endpoints() or similar, and one of the resulting revision numbers was passed up the call stack a bit, and then some function was called to trace the history of the branch back to that revision to find the corresponding URL. If get_range_endpoints() would return the full location then that subsequent look-up wouldn't be needed. + Here's an example of how useful working with path-revs can be, beyond mere notational convenience. I thought I saw (but can't find it at the moment) a call to svn_mergeinfo_``_get_range_endpoints() or similar, and one of the resulting revision numbers was passed up the call stack a bit, and then some function was called to trace the history of the branch back to that revision to find the corresponding URL. If get_range_endpoints() would return the full location then that subsequent look-up wouldn't be needed. === One way to store the resulting mergeinfo into the WC === Several functions support two ways: write mergeinfo straight to the WC, or return it to the caller and let the caller write it to the WC. For example, see "result_catalog" parameter of do_merge(). It is not clear that the two implementations currently produce equivalent results, as presumably they should. We should have just one way. The latter seems the one to choose because that would support all existing usage and also would seem to be a good way to enable better kinds of "dry run" implementation.
