Timofei Zhakov wrote on Sat, 23 Nov 2024 21:39 +00:00: > [...] > >> However, there are some technical limitations in the current merge >> implementation, which prohibit it to be used outside of the merge >> command, but the merge implementation can be split onto two files; the >> merge itself and the "apply" tree-processor. >> >> I have a prototype of factoring-out the "apply" tree-processor from >> merge. In general it seems to be working with most test cases passing. >> Additionally, as you might already have seen, I committed some >> improvements a while ago, which are related to this. > > [...] > >> I am planning to do the following to implement binary patches: >> >> 1. Factor-out "apply" tree-processor from merge.c to another file of >> private client API. > > [...] > > I just created a branch for this in r1922042 > <https://svn.apache.org/r1922042>: branches/apply-processor > <https://svn.apache.org/repos/asf/subversion/branches/apply-processor>. > > I am going to move some code from merge.c to merge_processor.c, and then > resolve the issues and fix the tests.
Timofei, I'd like to make sure that you aren't making the mistake of assuming dev@ has agreed that the stated problem should be solved using XML-serialized svn_diff_tree_processor_t drives. On this instance, you can assume lazy consensus for the problem statement: if no one disagrees, that means that yes, it's a problem we should solve. However, on this instance you shouldn't assume lazy consensus for the proposed solution: for one, both Nathan and I are refraining from commenting on the XML approach, because you said you hadn't finished describing it. So, if you'd like to prototype the XML approach, by all means do so; and if you'd like to do so on a feature branch in this repository, all the better; and if some of the initial parts improve merge.c in manners of independent interest, that's pure win, as far as dev@ is concerned. However, all that being said, don't operate on the assumption that the problem you stated will be solved in 1.15 using the solution you stated and have been prototyping: that might or might not happen, depending on the outcome of the design discussion which will commence once you have "explain[ed] in detail the format". Looking forward to the discussion, Daniel
