Greg Stein wrote:
> I'm not sure this has anything to do with Ev2. The editor is for making the actual changes; ie. examine the merge sources, and if acceptable, then you call svn_editor_delete() to perform the deletion. The merge logic is in the *driver*, not the receiver.
The way merge works is: client requests the source-side diff from the repo. Repo sends this diff (e.g. r10:20 branchA) via an 'editor'. Client (receiver of this edit drive[1]) knows about the target-branch (branchB) and how that differs from the base (r10 of branchA). Client figures out what changes to apply to the target branch -- which will be some of the incoming diff's changes, and some changes that aren't quite the same as in the incoming diff, and some other changes that the client decides it needs. Client applies these changes to the WC -- which it could theoretically do via another editor but it just does it directly.
So the editor is being used to transmit a diff between two repo trees, not driven by merge code.
[1] Actually the client first converts the callbacks from the 'delta_editor' into svn_wc_diff_callbacks-style calls, adding some of its own information in the process, in a not very clean way.
- Julian
>Cheers,
>-g
>On Feb 29, 2012 5:59 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>
>I've been briefly considering about issue #3150 again.
>>http://subversion.tigris.org/issues/show_bug.cgi?id=3150
>>"tree conflicts with directories as victims"
>>
>>The problem of this issue is that, during a merge, when deleting a directory,
>>we want to know whether the merge is deleting the same content from the
>>target branch that was deleted in the source branch. If the content
>>matches, there is no tree conflict. Else, there is a tree conflict.
>>
>>We tried to solve this problem in the current design during the 1.6
>>release cycle. It turned out to be quite hard. So I hope editorv2 will
>>help here.
>>
>>But it seems the current signature of the svn_editor_delete() callback
>>is suboptimal. It accepts a path and a revision:
>>
>> * Delete the existing node at @a relpath, expected to be identical to
>> * revision @a revision of that path.
>>
>>It seems the idea is that, during a merge, the receiver would compare
>>the directory being deleted in the target to relpath_at_revision in the
>>source branch. Correct?
>>
>>Since we now discourage merges into mixed-revision working copies,
>>this might actually work.
>>
>>But is this the best way of dealing with this problem?
>>Not only will the receiver have to recursively list the entire
>>relpath_at_revision in the merge source, it will also need to get
>>all file content (or checksums thereof) in this subtree to figure
>>out whether the deleted subtrees are equal. This implies a lot
>>of additional RA roundtrips.
>>
>>What if we allowed the driver to optionally specify a hash map tha
>>maps relpaths of all children in the deleted subtree to the either
>>a SHA1 checksum of content (for files), or lists of children (for
>>directories)? That would allow the driver to provide the necessary
>>information upfront, to be marshalled across the RA layer in one go.
>>
>
>
Received on 2012-02-29 14:06:06 CET