On Wed, Feb 29, 2012 at 16:55, Stefan Sperling <[email protected]> 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@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@R", and the receiver says "I have P@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@10, @20, and Target: patch = compute_diff(S@10, S@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
