I'm looking at merge code improvements, with the ultimate aim of
functional improvements. My immediate aim is finding ways to
restructure parts of the code to make it simpler to understand and
easier to work with.
Right now I'm looking at rationalizing the way a repos-repos diff is
generated. In any merge the data flow starts with
libsvn_client/repos_diff.c generating a diff between two repository
trees and driving merge.c through the "diff callbacks" mechanism. The
same diff editor is also used for "svn diff" in the repos-repos case,
but whereas that's the only source of changes for a merge there are
other sources for "svn diff".
Here's a few things I'm planning to try, ordered from easy to hard:
* The merge passes a WC path into the repos-repos diff editor. (Diff
doesn't.) Eliminate this, as it is irrelevant to a repos-repos diff.
It is only used as a convenience prefix on paths sent to the callbacks,
plus in one small place to adjust a notification for part of the new
local-move functionality. I'm currently working on this; see email
thread "svn commit: r1161219 - Auto-resolve 'local move vs. incoming
edit'" <http://svn.haxx.se/dev/archive-2011-08/0586.shtml>.
* Eliminate "WC props" and "entry props" from the prop-change diff, if
possible. (Diff doesn't want to know about them; I need to check
whether merge does.)
* Eliminate notification from the repos-repos diff editor. Again,
only used by merge, not diff. Notification basically duplicates some
information that the diff callbacks are supplying. Bert advises that
this would be hard to do but good. One complication I've noticed is
that 'absent' dirs/files are currently notified but there's no 'absent'
indicator in the diff callbacks mechanism.
* Think about all the "skip this item" and "note that this item hit a
tree conflict" feedback mechanisms and see if there's a way to make them
less specific to merging and hopefully simpler. (It seems wrong for the
repos diff code to have parameters that tell it about a "tree conflict"
because it should not know anything about such a concept.)
I'll see how many of these particular ideas pan out. This is more of a
heads-up that I'll be looking for any such opportunities.
- Julian
Received on 2011-08-30 13:47:17 CEST