Re: [PATCH]implement a FIXME for handling moved paths in copyfrom_info_receiver

On Sat, 26 May 2007, Kamesh Jayachandran wrote:
...
> >Kamesh, I had something in mind more along the lines of the patch
> >below. Your patch seems to have a different intent. I am sure that
> >we should be using strict node history; lenient history could turn up
> >nodes that aren't true copies.
...
> I misunderstood " /* ### FIXME: Look for moved parents of target_path. */".
>
> My patch's intension is different.
>
> The intension is if you want to get a copy source on '/abc'(which is
> renamed from /xyz) we will get '/xyz' as copy source path which does
> not exist on HEAD(due to rename).

Copy sources include peg revision numbers, so I think this isn't an
issue.

> Can you elaborate a bit on '/* ### FIXME: Look for moved parents of target_path. */".'?

If you have "/branches/foo/bar", and "/branches/baz/bar", and "baz"
was a copy of "foo", I want to detect that when running 'log' on
"bar". As the code stands in the repository today, we won't detect a
copy source for "bar", because 'log' will only list "baz" as a changed
path. Example:

$ svn log --verbose branches/baz/bar
------------------------------------------------------------------------
r2 | dlr | 2007-05-25 19:11:55 -0700 (Fri, 25 May 2007) | 1 line
Changed paths:
   A /branches/baz (from /branches/foo:1)

create branch
------------------------------------------------------------------------
r1 | dlr | 2007-05-25 19:11:33 -0700 (Fri, 25 May 2007) | 1 line
Changed paths:
   A /branches
   A /branches/foo
   A /branches/foo/bar
   A /branches/foo/bar/hello-world.txt

initial content
------------------------------------------------------------------------

I've evolved the previous patch I posted to try and handle this case.
What I wasn't sure about is if _both_ "baz" (a parent directory) and
"bar" (the actual directory I'm interested in) can show up as copies
in a commit. If you have a chance, it would be great to get a
regression test for this functionality (the JavaHL bindings currently
have a simple one).

If they can (and I haven't thought through this yet), we need to try
and get "bar" before paying attention to any ancestors. I think we'd
be able to do this easily by sorting the changed paths before
processing them. Do you think this is necessary?

- Dan