I've been briefly considering about issue #3150 again.
"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
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 11:59:39 CET