Stefan Sperling 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.
Or, more succinctly, delete() could take a single "hash-digest of the node" parameter. Defined something like:
For a file node, the node-digest would be:
node-digest := sha1(props-digest, content-digest)
For a directory node, the node-digest would be:
node-digest := sha1(props-digest, dir-digest)
where:
content-digest := sha1(file-content)
dir-digest := sha1(the {entryname->node-digest} map in deterministic order))
props-digest := sha1(the {propname->propval} map in deterministic order)
These node-digests would be potentially very useful for things like 'svn update' avoiding the server having to transmit to the WC any nodes that the WC already has. It's the logical extension of the current use of SHA1 for file content, but simply extended to whole nodes and node-trees.
- Julian
Received on 2012-02-29 12:23:13 CET