On 1/25/07, Vlad Georgescu <firstname.lastname@example.org> wrote:
> 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:
> 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.
Huh. But won't it be too late by the time we get back to
path_driver_cb_func? Won't add_subdir have already closed the parent?
In fact, now that I think about it, I'm not convinced that this
"handle things in add_subdir and make path_driver_cb_func ignore it"
function is correct anyway, even if it happens to work; won't
svn_delta_path_driver end up calling a bunch of open_directories to
get to the things that we've ignored? ie, in the case of
svn cp /private/bla /public/trunk
svn ps foo bar /public/trunk/bla/a/b/c
won't we end up with
add_subdir: add_directory /public/trunk/bla
add_subdir: add_directory /public/trunk/bla/a
add_subdir: add_directory /public/trunk/bla/a/b
add_subdir: add_directory /public/trunk/bla/a/b/c
add_subdir: close_directory /public/trunk/bla/a/b/c
add_subdir: close_directory /public/trunk/bla/a/b
add_subdir: close_directory /public/trunk/bla/a
svn_path_delta_driver: open_directory /public/trunk/bla/a
svn_path_delta_driver: open_directory /public/trunk/bla/a/b
path_driver_cb_func: [do nothing]
etc? That is, even if we are preventing path_drier_cb_func from doing
anything serious, there's still the implicit open_directory and
close_directory calls in svn_path_delta_driver.
> 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.
Ah, the latter here definitely makes sense. Hopefully you can
convince my that my other worries are unfounded too...
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jan 25 15:33:04 2007