Stefan Sperling <stsp_at_elego.de> wrote on 04/03/2008 11:31:08 AM:
> On Thu, Apr 03, 2008 at 08:57:47AM +0200, Nico Schellingerhout wrote:
> > Stefan Sperling <stsp_at_elego.de> wrote on 04/02/2008 07:46:17 PM:
> > >
> > > How do we define modification of a directory?
> > > Is a directory modified only when direct children are removed/added?
> > > Or are there other cases?
> > I think modification means: modification anywhere in the subtree
> > rooted by the directory under consideration, including properties
> > on that directory.
>
> Hey Nico,
>
> I think defining the behaviour for only for a single directory is
> enough. I mean, for any kind of directory modification, we need
> only look at the direct children of a given directory.
>
> 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?
The same argument could be given for modifications at any depth in the
tree. Hence, the necessity to check the _entire_ subtree.
>
> The corresponding 'svn merge' output to the above scenario might look
> like this:
>
> G dir1/dir2/dir3/a
> C dir1/dir4
That is what I would expect.
>
> Starting another subtree crawl while we are already crawling the tree
> anyway is not a good idea, IMHO. My concerns have nothing to do with
> performance here, I'm simply arguing about the complexity of the design
> and the complexity of the resulting implementation.
If it can be done in a simple manner, I agree, of course.
>
> I'm not sure if you were implying spawning another crawl, but I want to
> make sure we have the same idea about what "modification of a directory"
> is supposed to mean.
I think we agree on what a modified dir is, but I'm not convinced that
your arguments about the crawling are correct.
- Nico
Received on 2008-04-03 17:29:18 CEST