Re: tree conflicts and directories discussion

On Thu, Apr 03, 2008 at 05:30:17PM +0200, Nico Schellingerhout wrote:
> Stefan Sperling <stsp_at_elego.de> wrote on 04/03/2008 11:31:08 AM:
> > The recursive behaviour you want should come for free with the
> > the way the merge operation walks the tree (depth first).
> > I mean, suppose we had the following scenario during a merge:
> >
> > The diff wants to change the files 'a' and 'b' in these directories:
> >
> > dir1/dir2/dir3/a
> > dir1/dir4/dir5/b
> >
> > The user has locally delted dir1/dir4/dir5 (and hence all its content).
> >
> > Now, if I understand correctly, with your definition, flagging the tree
> > conflict at dir1 would be allowed: "modification anywhere in the subtree
> > rooted at the directory under consideration" -- the directory under
> > consideration happening to be dir1, for example.
> >
> > But this is redundant. The conflict can also be flagged directly
> > at dir4, the direct parent of dir5. And this not only has the same
> > effect as flagging it at dir1 (the effect being that a tree conflict
> > is signalled), but it's also a much simpler design that is much easier
> > to implement.
> This looks ok for UC 1 and 4, but what about 2 and 5:
>
> Source:
> dir1/
> dir1/a
> dir1/b
>
> Target:
> dir1/
> dir1/a
> dir1/b'
>
> Revision on Source to be merged to target:
> D dir1
>
> What happens?
> If the algorithm crawls in the order dir1/a, dir1/b, dir, then dir1/a
> will be deleted (no modification, therefore delete is ok), and tree
> conflict when dir1/b is reached. The WC will then look like:
>
> C dir1/
> dir1/b'
>
> Right?

Seems to be the case. Michael Pilato just told me that Subversion
visits children of deleted directories to check for unversioned
items before pruning the subtree. So yes, with the current code,
this is probably what would happen.

But I don't understand why you stop your example at a point before
the deletion of dir1 is actually carried out. Because that is what
I think we are trying to define: The behaviour we want from Subversion
in all our tree conflict use cases, but with directories instead of
files as victims. Our entire current tree conflict design is only
about files as victims. We cannot implement anything before we've
defined how tree conflicts should behave with directories as victims.

> The same argument could be given for modifications at any depth in the
> tree. Hence, the necessity to check the _entire_ subtree.

I don't see how your example contradicts with not doing a full subtree
crawl anytime we find a use case 2 or use case 5 tree conflict with
a directory as the victim.

I think your example is a good one, because I hadn't thought of this
scenario yet. But all that comes to my mind about it is that,
when dir1 is deleted, which contains tree conflict victim dir1/b',
and the deletion of dir1 itself causes a tree conflict, we can either

1) forget about that dir1/b' is a tree conflict victim,
   saying that the tree conflict with victim dir1 supersedes it

or

2) don't discard any information but record dir1 as
   an additional tree conflict victim

We'd need to think through the consequences of either action
and then decide what we want. There may be other things we could
do that I've overlooked. But the point is that we need to define
some behaviour.

> I think we agree on what a modified dir is, but I'm not convinced that
> your arguments about the crawling are correct.

My arguments may well be incorrect as long as I haven't fully understood
all problems involved yet. Which I apparently haven't, since I have
trouble understanding your point against not doing a crawl :(

-- 
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