Stefan Sperling <stsp_at_elego.de> wrote on 04/03/2008 06:28:13 PM:
> 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.
>
Ok. That's good.
> 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.
You're right, of course. I was thinking out aloud, not having reached
a definite conclusion. My implied suggestion was that dir1 should not
be deleted, but left in conflict in the working copy.
>
> 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
I think the second option is better: the user needs to understand that
the action that led to the conflict is the delete of dir1, but also
should get hints at what he has to do to fix the conflicts. Therefore,
a conflict on the modified files/dirs should be raised as well.
Let me see if I can sketch an example, to start off the discussion:
Start on source:
dir1/
dir1/a
dir1/b
dir1/dir2/
dir1/dir2/c
Revision to merge:
D dir1
Start on target:
dir1/
dir1/a
dir1/b'
dir1/dir2/
dir1/dir2/c
dir1/dir2/d
I would like to see the merge to have something like the following result:
C dir1/ [could not be deleted because of local modifications in b' and
dir2]
dir1/a
dir1/b'
C dir1/dir2/ [could not be deleted because file d is not in the source
branch]
dir1/dir2/c
dir1/dir2/d
This gives the user the information needed to solve all problems in a
systematic manner.
>
> 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.
See my proposal above.
>
> > 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 :(
>
Perhaps the above example helps. The problem is that I do not understand
the merge algorithm in sufficient detail to predict what would happen,
and that is why I raised the issue. Given the complexity of merging,
we're probably both wrong ;)
- Nico
Received on 2008-04-04 11:07:55 CEST