I (Julian Foad) wrote: > I (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>.
Done in r1163238 and r1163296. - Julian > > * 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
