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
Received on 2008-07-05 18:39:59 CEST