On Tue, 2011-08-30 at 12:46 +0100, Julian Foad wrote:
> 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.)
Well, that was naïve. Merge does want to know about entry-prop changes.
> * 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 14:05:39 CEST