C. Michael Pilato wrote:
> Tonight I was wondering who made use of svn_fs_get_mergeinfo_for_tree()
> (because I wasn't happy about the fact that it uses a filtering function
> instead of just being streamy/callback-y like so many other of our APIs).
> The only consumer appears to be 'svn log -g', which is using it to filter
> out "branching copies" based on, I think, whether or not the copy resulted
> in a mergeinfo diff that matches what you'd expect when doing a copy. Only
> problem is, what we now expect when doing a copy is no mergeinfo change at
> all, right?
> Has this code been updated since we made these changes to the 'copy' behavior?
No. I've been working on updating the tests to actually reflect the
current copy and merge behavior on trunk (this is happening on the
fix-log-mergeinfo-tests branch). I hope to have this finished soon.
After that, I'll need to see which tests are failing as a result of the
changes to 'copy' behavior, and then fix them. The filter function was
an ugly hack from the beginning, and I will be happy to see it go.
> (My primary goal with this question is that I'd like to know if we can lose
> svn_fs_get_mergeinfo_for_tree() before I go and try to implement it anew on
> the 'reintegrate' branch.)
Understood. I'll see what I can come up with in the next day or two.
Received on 2008-01-08 18:45:37 CET