On Thu, 5 Apr 2007 17:34:53 +0100, Malcolm Rowe wrote:
> On Thu, Apr 05, 2007 at 05:59:28PM +0200, Vincent Lefevre wrote:
>> The following bug occurs with Subversion 1.4.2 and 1.4.3 at least:
>>
>
> Confirmed on 1.4.0 and trunk (with variations).
>
>> vin:~tmp/wc> svn rm foo
>> D foo
>
> (On trunk, this fails because 'foo' has local mods, so you need
> --force.)
>
>> vin:~tmp/wc> svn mv bar foo
>> A foo
>> D bar
>> vin:~tmp/wc> svn pl -v foo
>> Properties on 'foo':
>> svn:mime-type : text/plain
>
> On trunk, the situation's even worse - foo's properties disappear here.
>
> Regards,
> Malcolm
>
It's possible/probable this is unrelated, but I find it a strange
coincidence that we encountered a bug relating to 'svn rm' this week where
the working copy seems to be messed up following a seemingly successful
commit of a deletion of a directory:
% svn rm deleteme-dir
D deleteme-dir/subdir/file1
D deleteme-dir/subdir/file2
D deleteme-dir/subdir/file3
D deleteme-dir/subdir
D deleteme-dir/file4
D deleteme-dir
% svn ci deleteme-dir -m ""
Deleting deleteme-dir
Committed revision 20
% svn cp . <tag-URL>
svn: Commit failed (details follow):
svn: Directory '/working_copy/deleteme-dir' is missing
svn: Your commit message was left in a temporary file:
svn: 'svn-commit.tmp'
If you do an update of '.' prior to doing 'svn cp', this problem doesn't
occur. However, in many situations you would not want to update . since you
are trying to tag the exact data in your working copy at that point. It
appears that the committed deletion of the directory is not properly
updating the metadata for the parent dir? When I look in the entries file
for '.', it still lists 'deleteme-dir' as being one of the entries. Running
'svn status' on it does not show 'deleteme-dir' as being out-of-date or
missing.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 8 04:30:47 2007