[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tree conflicts and directories discussion

From: Nico Schellingerhout <nico.schellingerhout_at_philips.com>
Date: Thu, 3 Apr 2008 17:30:17 +0200

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:



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/


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.