CODEWITHSUNDEEP
svntortoisesvn
Vilx-
Vilx-

Reputation: 107002

SVN local working copy has a file that has been removed on the server

I've got a project I'm working on and I'm using TortoiseSVN for version control (latest). I'm the only person that has ever worked on the project.

Some time ago I was moving around filed and folders in that project. The version history tells me that a single commit was responsible for moving and deleting some files. Like this:

PATH                  ACTION       COPY FROM FOLDER
===================================================== 
/some/folder          REPLACING    /some/other/folder
/some/folder/file1    DELETED
/some/folder/file2    DELETED

Now this is a mistake on my part. I never meant to delete those two files. It was meant to be just a copy operation. But no worries, right? It's a source control after all.

However now there's weirdness there. When I look at /some/folder, I see that the file1 and file2 are still there. Not only that, they are still marked as under revision control. Tortoise fully believes that they are a part of my local working copy. Trying to view the history of the files also gave an error about an incorrect URL, until I performed "Clean-up" on the working copy.

Now I can see the history of the files, but the last commit still states that they have been deleted, and performing an update on another computer doesn't place the files there. Also, changes to these files cannot be committed.

WTF? O_o

Update: What I'd like to know is how and why this came to be. It was probably my own fault, since I did a lot of file renaming, including things like deleting a folder and copying another folder in its place, all in the same commit. But it still shouldn't create such a confusion. So... WAT?

As for fixing it, I suppose I could do that myself. I can just download another working copy and add the files back through that, end of story. But in this case, I want to understand what it was that caused it, how to reproduce it, and if I should maybe submit a bug to the SVN team. :P

Upvotes: 2

Views: 444

Answers (1)

David W.
David W.

Reputation: 107080

Why did this happen? That's a hard question to answer. However, I know this type of stuff happens a lot with TortoiseSVN. It's not so much a problem with the program, but usually due to human error.

TortoiseSVN uses Windows Explorer's interface, and that can be an issue. In Explorer, I'm use to renaming, dragging, and dropping, and deleting files at the press of a button. Unfortunately, none of those things I tend to do with Explorer work with Subversion.

With TortoiseSVN, if I wan to move a file that is in my working directory, I have to use the TortoiseSVN context menu. If I want to rename a file, I have to go to the TortoiseSVN context menu. It's a break in the way I normally interact with Explorer, and it's very easy to forget.

One thing you have to remember is that a working copy may itself not be all on the same revision. Different folders and even different files can be at different revisions. You can easily see a file that no longer exists in the repository if it so happens that the folder you're looking at is at an earlier revision than the one in the repository.

In fact, that's another issue I have with TortoiseSVN. TortoiseSVN doesn't really relay that type of information to you.

By the way, I do use TortoiseSVN on Windows. However, I must keep myself aware of the issues I mentioned when I use it, or else I find my repository and my working directory not in a complete state of agreement.

I heavily use the command line client that comes with TortoiseSVN. I find the command line client can be more informative and easier to get things back in sync. I recommend anyone who uses TortoiseSVN to learn the command line client and use it in situations where TortoiseSVN can lead you astray. 90% of my commits are done via the command line client, and I do a lot of svn status commands with the command line client. I find it keeps TortoiseSVN in check.

One more thing: Don't copy the files back and add them back in. To Subversion, these are brand new files with no history associated with them. To you, there are a continuation of the previous file. In a few weeks hilarity will ensue when you suddenly find something is not quite right with a merge.

Instead, copy the file from the old revision to the current working directory:

$ svn cp -r30 ^/trunk/my_file@30 .

This will link revision 30 (assuming that was the last revision of this file before it was deleted) to the current working copy. The history will be correct, and both you and Subversion will agree on the status of that file.

Upvotes: 2

Related Questions