views:

833

answers:

4

What does a TortoiseSVN actually cleanup do?

I have not found a pattern, but I frequently get asked to do a "cleanup" while trying to commit code.

UPDATE:

If TortoiseSVN knows when its dirty... Why doesn't it run a cleanup itself!?!?

+2  A: 

It looks for inconsistencies. From the docs:

If a Subversion command cannot complete successfully, perhaps due to server problems, your working copy can be left in an inconsistent state. In that case you need to use TortoiseSVN → Cleanup on the folder. It is a good idea to do this at the top level of the working copy.

Cleanup has another useful side effect. If a file date changes but its content doesn't, Subversion cannot tell whether it has really changed except by doing a byte-by-byte comparison with the pristine copy. If you have a lot of files in this state it makes acquiring status very slow, which will make many dialogs slow to respond. Executing a Cleanup on your working copy will repair these “broken” timestamps and restore status checks to full speed.

Ben S
A: 

See here under "New External Status Cache".

Jason Punyon
+4  A: 

Edit: I think it's not automatic as it needs to abort operations and unlock the working copy in /path.

Subversion book:

Recursively clean up the working copy, removing locks and resuming unfinished operations. If you ever get a working copy locked error, run this command to remove stale locks and get your working copy into a usable state again. ” Note that in this context lock refers to local filesystem locking, not repository locking.

It's basically a way of trying to recover any errors that occur with SVN.

Documentation on cleanup:

http://tortoisesvn.net/docs/release/TortoiseSVN%5Fen/tsvn-dug-cleanup.html

"If a Subversion command cannot complete successfully, perhaps due to server problems, your working copy can be left in an inconsistent state. In that case you need to use TortoiseSVN → Cleanup on the folder. It is a good idea to do this at the top level of the working copy.

Cleanup has another useful side effect. If a file date changes but its content doesn't, Subversion cannot tell whether it has really changed except by doing a byte-by-byte comparison with the pristine copy. If you have a lot of files in this state it makes acquiring status very slow, which will make many dialogs slow to respond. Executing a Cleanup on your working copy will repair these “broken” timestamps and restore status checks to full speed."

Andi
I don't get it every single time, but I see it pretty often.
SkippyFire
I know this doesnt help but i havent seen the message at all and ive been using it for about a year now. Is it when you commit or just randomly?
Andi
Sorry re-read your post, you do you commit over wireless or are you prone to network issues in general? maybe that could have something to do with it. Is it being stored within your local network or are you storing the commit's remotely?
Andi
NO we don't have any network issues. It's on the local network. As I said, it's not every time, it just seems to happen randomly. I'm guessing that I am doing something that is causing this. Moving files, deleting files or something...
SkippyFire
+2  A: 

it puts duct tape over bugs and dumb architecture in SVN which allow the working copy to be corrupt. Its not automatic for dumb architecture reasons and because it takes FOREVER. Of course, when SVN got popular its architecture was miles ahead of CVS.

Dustin Getz