On Wed, Feb 29, 2012 at 16:55, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Feb 29, 2012 at 08:19:52AM -0500, Greg Stein wrote:
>> The editor interface is not for merging. It is for *applying* the results
>> of a merge, to a stateful representation of a tree to alter that held state.
>
> Sorry, but I still don't understand how you want to solve the problem.
>
> You seem to be saying that we shouldn't be loocking for a solution
> in the Ev2 API.
Correct. it does not do merge. The drivers says "set PATH to state
FOO", and it does it. There is no "well, maybe store a conflict and
don't make the change" going on there.
> So where should we look? How will the merge driver
> you speak of decide whether or not to flag a tree conflict in the delete
> vs. delete case under discussion?
The merge driver says "delete P_at_R", and the receiver says "P doesn't
exist [cuz somebody already deleted it]". So the driver records a
delete/delete conflict.
Or the merge driver says "add P", and the receiver says "P already
exists", so the driver records an add/add conflict.
Or driver says "add P, replacing P_at_R", and the receiver says "I have
P_at_R+1", so the driver records an add/edit conflict.
etc.
> And where will the merge driver run?
Dunno.
> Right now, we have delta_dirs() on the server as the merge driver.
> How will that change with Ev2?
delta_dirs() comes up with a list of edits to change a tree from state
1 to state 2. It is not a merge driver. There is no change in moving
to Ev2 except in the APIs used to describe that change.
The merge process takes two sources and one target. This is why I say
that Ev2 is not part of the merge process. You must compute the
difference between the sources, how that applies to the target (yes,
using out-of-editor query functions about the target), and then call
Ev2 to apply the desired outcome. The merge process then records
whatever conflicts as appropriate.
Okay... all that said, here is another perspective. Consider the
update_editor. Changes arrive which say "set BASE to $this." This can
create all sorts of conflicts, which we currently handle within the
update_editor and potentially interactively. During wc-ng development,
I said that I believe the BASE tree should be changed as told, and the
conflicts against current-state recorded. At the end of the update,
you have a BASE tree matching the server, some local mods, and some
conflicts. Process the conflicts at that point.
For example, let's say you locally added a file. The server adds the
same file. So you update BASE with the server-added file, and then you
change your local-add to a local-replace and flag a conflict.
Or you have locally deleted a file, and the server edits the file.
Update BASE to the new server's contents, keep the file
locally-deleted, and record a delete/edit conflict.
etc.
"svn merge" is nothing like the update process, however. It isn't "set
BASE to FOO", so it is a very different beast. Whether it runs in
svn_wc or svn_client... dunno. Depends on how much information is
needed, I guess. It is *likely* in svn_client so that you can fetch
server content, so you can interact with the user, etc.
I suspect that all conflicts will be recorded from the driver.
Consider the following simple example between Source_at_10, @20, and
Target:
patch = compute_diff(S_at_10, S_at_20)
new_T_contents = apply_patch(T, patch)
ev2->alter_file(T, new_T_contents)
That's the basic flow. Patches (aka svndiff/txdelta/whatever) do not
flow across the Ev2 interface. Just entire content streams. So the
driver needs to compute the new contents.
But what if apply_patch() generates a conflict? This is *before* you
invoke alter_file().
[ conceivably, you could streamily apply the patch, and (thus) as
alter_file() read new_T_contents, the patch just gets applied
on-the-fly... but that gets in the way of managing text conflicts ]
As you can see: Ev2 plays a very small part in the "svn merge"
process. It is only used to change the WC once a decision has been
made. It also has no mechanisms for conflict handling, though i can
arguably see it should. ie. ev2->record_text_conflict(T, source_left,
source_right)
But the short answer is: we have no design for conflict management in
Ev2. Thus, there will be a ton of out-of-band communication between
the merge process and the underlying state. Both reading, and writing
conflict information.
Hope that helps,
-g
Received on 2012-02-29 23:31:22 CET