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=3&rev2=4 === Use svn_client__pathrev_t more widely === + (Difficulty: several quite simple sub-tasks, and some harder bits) + 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. @@ -21, +23 @@ . I'd recommend being wary in your work about the struct being an *input* param in public APIs. There are seriously heavy internal constraints on the struct members. (eg. pass a struct with a NULL uuid, or even a non-matching one). I don't have a recommendation right now for what happens if the struct is made public. I just wanted to raise a yellow flag. It seems best to keep it very private because of the difficult constraints/preconditions in its members. [...] It may be as simple as only returning const structs in the API. Or opaque. But certainly warnings like, "seriously, don't mess around in here. tweak at your own peril." :-) === One way to store the resulting mergeinfo into the WC === + (Difficulty: straightforward in theory, moderately complex in practice) + 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.
