[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

failed to add directory

From: Dħbrowski, Leszek <ldabrowski_at_ivmx.pl>
Date: Mon, 6 Dec 2010 17:47:00 +0100

Hello,
I encountered the behaviour that looks like a bug.
I work with a quite big repository (local copy on my PC (x86, winXP SP3) has about 8GB
I did the following.
I started with the directory tree marked by the overly icon "normal" at the trunk node, I believe, that all was correct.
I start with the .xls file on the 8th level of the directory tree (with trunk on 1th). The file needed acquiring a lock to be changed.
1. I opened the file with MSexcel and tried to write it. Excell refused to do it, I closed excel.
2. I got the lock and opened the file again. I tried to write it, excel refused to do it because it thought that the file is read-only. I wrote the file with modified name
3. I closed the excel
4. I renamed the file to its original name using the file manager. It asked about overwriting, I confirmed.
Now I had modified file, which had not been committed.
5. I tried to do update on the trunk. svn marked with the red "modified{" icon the branch of the directory tree ( all its nodes, except the file itself) in which the file was located
6. I renamed the modified file and then I did the update on the trunk The last revision of the file was written in my local copy, but the tree still had been marked wit the "modified" icon .
7. I did the update of the trunk once again and I got the following error message:

Command: Update
Error: Failed to add directory 'E:\ld\pgnig\new_repo\trunk': a versioned directory of
Error: the same name already exists
Finished!:

I did the clean-up on trunk, svn reported it to be successful, but the next update on trunk ended with the same error message.

I used the following version:
TortoiseSVN 1.6.12, Build 20536 - 32 Bit , 2010/11/24 20:59:01
Subversion 1.6.15,
apr 1.3.8
apr-utils 1.3.9
neon 0.29.5
OpenSSL 0.9.8p 16 Nov 2010
zlib 1.2.3

I encountered this behaviour several times, usually I had to remove the reported directory and get the fresh copy with update, but the size of the repository is too big to mean this as a valuable work-around

Sincerely yours,
Leszek Dabrowski
Received on 2010-12-06 18:39:47 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.