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.
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 13:28:19 CET