Re: [PATCH] copy file to existing directory.

Sorry, I just fogot to attach the patch in my previous post.

Rui
On Sun, Jul 06, 2008 at 12:39:43AM +0800, Rui, Guo wrote:
> Hi all,
> I found some problems in the copy sub-command while trying to make 'svn cp'
> works when the destination is a excluded item. I found a suspicious code in
> copy_file_administratively(). I then did some experiments and verified my
> suspect. The problem is that, the checking of existing destination does not
> cover the situation of directory. The following commands can trigger the
> problem:
>
> svn co http://server/greek_tree wc
> cd wc/A/B
> rm -rf F
> svn cp lambda F
>
> The error output is like this:
>
> subversion/libsvn_wc/log.c:1602: (apr_err=155020)
> svn: In directory '.'
> subversion/libsvn_wc/log.c:1602: (apr_err=155020)
> svn: Error processing command 'modify-entry' in '.'
> subversion/libsvn_wc/log.c:861: (apr_err=155020)
> svn: Error modifying entry for 'F'
> subversion/libsvn_wc/entries.c:2475: (apr_err=155013)
> svn: Entry 'F' is already under version control
>
> And even an 'svn cleanup' can not bring the wc back to work, which is quite
> annoying. After correcting the check, I get this output instead:
>
> subversion/libsvn_client/copy.c:536: (apr_err=155007)
> svn: Path 'F' is not a directory
>
> The error prompt is kinds of confusing. The reason is that, the code in
> libsvn_client will try to copy the source into the target directory if it
> exists and the check is not perfect. More effort is needed. Please see the
> patch for detail.
>
> [[[
> Check the existence of target directory on copy.
>
> * subversion/libsvn_subr/io.c
> (svn_io_copy_dir_recursively): Use SVN_ERR_FS_ALREADY_EXISTS instead of
> SVN_ERR_ENTRY_EXISTS.
>
> * subversion/libsvn_wc/copy.c
> (copy_file_administratively): The same as above. Also check the existence
> of target directory.
>
> * subversion/libsvn_client/copy.c
> (wc_to_wc_copy, repos_to_wc_copy): The same as the first one.
> (svn_client_copy4): Only check SVN_ERR_FS_ALREADY_EXISTS.
>
> ]]]
>
>
> If we explicitly rm the destination, the result also changes.
>
> svn co http://server/greek_tree wc
> cd wc/A/B
> svn rm F
> rm -rf F
> svn cp lambda F
>
> result:
> subversion/libsvn_subr/io.c:2628: (apr_err=2)
> svn: Can't open file 'F/.svn/tmp/dir-prop-revert':
>
> This time the result is a little better, since the wc is still usable. Maybe
> somebody can makes it work better?
>
> Still, there is one more strange thing. After the directory F is removed both
> from revision control and the disk, the 'svn revert' unsurprisingly fails to
> finish its work. An 'svn update' can bring back the F directory. However, the
> 'delete' schedule flag of directory F in the parent entries is not cleared.
> Will it be harmful?
>
> Rui
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org