Re: svn commit: r16293 - trunk/subversion/libsvn_wc

dionisos@tigris.org writes:
> Log:
> Fix merge of added file where cwd is not on the same device as the target wc.
>
> * subversion/libsvn_wc/update_editor.c (install_file): Try copying the file
> when moving fails.
>
> --- trunk/subversion/libsvn_wc/update_editor.c
> +++ trunk/subversion/libsvn_wc/update_editor.c
> @@ -1943,10 +1943,17 @@
> pointing to parent_dir/.svn/tmp/text-base/basename. */
> if (strcmp (final_location, new_text_path))
> {
> - SVN_ERR_W (svn_io_file_rename (new_text_path, final_location,
> - pool),
> - _("Move failed"));
> + svn_error_t *err =
> + svn_io_file_rename (new_text_path, final_location, pool);
>
> + if (err)
> + {
> + svn_error_clear (err);
> + SVN_ERR_W (svn_io_copy_file (new_text_path,
> + final_location, TRUE, pool),
> + _("Move failed"));
> + SVN_ERR (svn_io_remove_file (new_text_path, pool));
> + }
> new_text_path = final_location;
> }
> }

Do we want to check that 'err' is the kind of error we expect (e.g.,
from a device-crossing failure, or lack of perms), before clearing it
and going on to the copy-delete method?

Now that the move takes place across two calls instead of one, what's
the justification for using SVN_ERR_W() for the first but SVN_ERR()
for the second? Also, The "Move failed" message on svn_io_copy_file()
is less appropriate than it was on svn_io_file_rename()... Maybe it
would make sense to write two custom wrapping messages, each
indicating that one half of a non-atomic move has failed, and use
SVN_ERR_W() for both?

Finally, although this might be premature generalization: maybe it
would be better to wrap the new functionality in a new API,
svn_io_rename_insist() or something, so that we don't reimplement this
logic in other places? At least, I know that I won't remember to look
back here in update_editor.c if this ever comes up again...

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org