On Thu, Nov 17, 2011 at 5:52 PM, Apache Wiki <wikidiffs_at_apache.org> wrote:
> Dear Wiki user,
> You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
> The "RepetitiveResolvingOfTheSameRename" page has been changed by PhilipMartin:
> New page:
> = The Aim =
> We want the merge to automatically apply incoming changes to the moved items. These are not uncommitted local moves, they are moves that have been committed to the repository. So the solution is to identify moves in the repository history and then use those moves to adjust the incoming merge differences so that they apply to the moved item.
No idea if this is relevant, but this sounds similar to
"variance-adjusted patching"  (a.k.a. diff4), but then for
tree-variances, and not only for text-changes.
From : "Variance adjustment is the process of transforming a patch
to account for differences that have arisen in the target text since
the patch was generated, so that the new patch will be applicable to
the new target text and yet still have the "same" effect as the old
patch. It is, in essence, patching a patch."
I don't know exactly why diff4 isn't actually used in our codebase
(for text-adjustments I mean) --- it's only used in
tools/diff/diff4.c. I guess that, apart from a shortage of tuits, the
reason may be the following observation (again ): "Note that the
algorithm is actually too powerful -- if taken to its logical limits,
it can generate patches that apply cleanly even when the user would
almost certainly prefer a conflict." Anyway, this all predates my
involvement in Subversion, so I really don't know.
> The idea here is to allow the user to resolve conflicts by telling Subversion "A moved to B" and storing that information.
Ok, so in case we can't (or can't yet) discover this information, we
may let the user tell us what kind of "variance-adjustment" needs to
be done (or put differently "what kind of adjustment took place
logically"), and store that information. Interesting.
Received on 2011-11-17 21:43:51 CET