views:

248

answers:

4

Hi

"Cleanup failed to process the following paths The system cannot find the file specified"

Am having this issue with Tortoise SVN going to a SAMBA share.. any thoughts on setup? Its probably permissions getting mucked up, but this setup doesn't feel very robust.. am having to delete the affected directory, then recreate from svn.

I do all my dev in notepad++ on the windows box, and use a windows shared drive through Samba.

Windows Vista laptop running subversion and tortoise.

Ubuntu8.10 running under VMWare which runs PHP4 and a old sybase_ct driver talking back to MSSQL on the host machine. I need this to mirror the production environment.

A: 

In my experience using Apache + SVN is a lot more robust than sharing a file repository, albeit harder to set up (probably not too bad with Ubuntu as it has apt)

Alternatively, you could use ssh+svn, i.e tunnel to the linux box.

Both methods eliminate samba and file sharing which sounds suspicious.

Frep D-Oronge
cheers..going to stick with Tortoise if I can!
Dave
I think the working copy is what is being shared via samba, not the repo itself
cdeszaq
A: 

I've had the same problem, and never managed to get to the bottom of it.

'Svn cleanup' worked on the Windows machine where the working copy actually was, but on the Linux machine (Fedora 10) which was accessing the working copy through Samba, each successive time of running that would give the message you quoted - but on a different directory.

Svn 1.5.4 by the way.

Colin

Colin Fine
Cheers...I think I may have fixxed it.. see below
Dave
A: 

I think I've found my issue:

http://tortoisesvn.tigris.org/faq.html#samba

In my /etc/samba/smb.conf file put in delete readonly = yes

fingers crossed....

Dave
+1  A: 

we have the same issue at work

often Tsvn (TortoiseSVN) has a problem to move folders created by itself, so we get an error like 'Can't move xxx to yyy...' 'Working copy locked, please cleanup' or something like, then the cleanup fails.

we tried with 'readonly = yes' in samba share definitions but it didn't work.

After that we find that folders created by the Tsvn creates folder with 444 or something like (readonly for the owner too), so that folders can't be deleted when it needs to move them. We solve the problem with 'force create mode = 600' in the share definitions.

And more, i tell you that you don't need to delete the entire project and checkout from SVN a new working copy when you're blocked with that error: it's enough to launch from shell this command when you are in the target shared root folder of the project

rm -rf `find . -type d -name .svn`

to remove the .svn folder recursively and then checkout (the files already there will be only re-versioned, not downloaded).

avastreg
great answer..to get rid of .svn files (in my case _snv) I used advanced search in Windows..
Dave