Hi,
David Glasser wrote:
...
> There's still one edge case that it doesn't handle correctly: Let's say we have
>
> /private/foo
> /public/trunk
> /public/bar
>
> (where private is unreadable by the syncer). Let's say we have a
> single revision that does
>
> svn cp /private/foo /public/trunk/
> svn cp /public/bar /public/trunk/foo/
>
> Before your patch, this would just fail (I believe). With your patch,
> I'm pretty sure (haven't tested it) that it will give you the correct
> files at the end, but /public/trunk/foo/bar and everything under it
> will be added one by one instead of copied from /public/bar. I think
> that can be fixed, though (I'll see if I get around to it).
This scenario is exactly why we need to iterate over the source path,
not the target path. In your example, we have the following changed paths:
/public/trunk/foo
/public/trunk/foo/bar
The first will he handled by add_subdir, which will add-without-history
everything under /private/foo. The second will be handled by
path_driver_cb_func, which will do an add-with-history.
...
>>> This feels very dirty, though. Does anyone have an opinion? (It also
>>> probably wouldn't work for newly added files inside the copied
>>> directory, I guess, unless you actually throw in a loop over
>>> changed_paths. Ick.)
>> In my testing it also works for newly added files. We should of course extend
>> the test case to cover this scenario.
>
> Hmm. I'm a little confused about why this works (need to test it
> myself): you're still iterating over dirents in the source, not the
> target, so it seems like you wouldn't pick up adds and deletes. (This
> is independent of the copy situation mentioned above.)
Like above, adds will be handled by path_driver_cb_func. Deletes won't
work, but we can simply check the type of the change in add_subdir, and
skip the directory entry if it's a delete.
I committed these two changes (the iteration over source, and the fix to
make deletes work) in r23231. I think we can close #2705 now.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 25 14:37:22 2007