Re: tree conflicts and directories discussion

On Thu, Apr 03, 2008 at 01:06:42PM +0200, Stefan Sperling wrote:
> On Thu, Apr 03, 2008 at 08:40:27AM +0200, Nico Schellingerhout wrote:
> > Stefan Sperling <stsp_at_elego.de> wrote on 04/02/2008 07:29:53 PM:
> > > Directories:
> > > If 'svn merge' deletes an existing directory, the directory is a tree conflict
> > > victim if its content is different from the corresponding directory
> > > on the left
> > > side of the merge source.
> > >
> > > Question here: What makes two directories "equal"? Do we need to consider
> > > all subdirectories of a directory? Or should we keep it simple and only
> > > consider direct children as in all the other cases?
> > > Warning: The former might perform quite badly!
> > I'm afraid the answer has to be: the former (see comment with use case 2).

> I agree that to be absolutely sure about the equality
> status of two directories, the subtrees of both directories need to
> be compared completely.
>
> > Performance may be bad, but should scale with the size of the tree being
> > deleted, so that should be acceptable. (It doesn't happen every day that
> > you rename your entire source tree.)
>
> I'm currently investigating how we could do this.
> I will try to provide more details later.

Here are some details:

It seems to me that it should be possible to implement this in a
relatively painless way. The proposal below requires a change to
the diff callback API. But since we're touching that already anyway,
that is not a problem.

When deleting a directory during merge, the merge_dir_deleted() callback
in libsvn_client/merge.c could trigger a depth-first traversal of the
tree in the working copy rooted at the directory to be deleted.

For each directory, it could retrieve the corresponding dir entry from
the repository as it existed in the merge-left source of the merge,
and compare the two for equality, i.e. check whether all fields in
the svn_dirent_t returned by the repo match their corresponding
attributes of the directory as found in the working copy.

The left-merge revision shall be a new additional parameter to
merge_dir_deleted(). The ra session needed to contact the repository
via the get_dir() method is already contained in the merge baton which
is passed to merge_dir_deleted().

As far as I can tell the performance overhead of this would be
N repository round trips for deleting a tree with N subdirectories.

Has anyone got serious objections, or should we go ahead and try
to implement it this way? If so, any ideas about alternative
approaches? I myself don't really feel competent enough to think
about what we could do on the server-side to help the client in
this case.

I'd especially like to get feedback from people who have experience
with the merge/diff editor, and/or the ra layer, and/or performance tuning.
(*hint* glasser *hint* -- I know it's not even 6AM in your timezone
yet, but I hope you get this message when you wake up -- Good Morning :)

Thanks,

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner