Delete missing files in SVN when committing snapshots

Question

I'm moving from StarTeam to SVN, and I've decided to take snapshots of each of our releases. However, I'm experiencing a problem when dealing with files which existed in revision 1 were deleted for revision 2.

How do I commit the snapshots when files are missing?

I've tried fully deleting the trunk/src/ folder and then replacing it with the new /trunk/src/ folder, but that seems to cause conflicts with missing files. When I svn add" everything, TortoiseSVN seems to detect that the files were missing, and when I commit it seems to attempt to delete the missing files, but it seems to fail. Presumably this is because it's trying to delete directories after deleting the files in that directory?

I'm getting the following error:

deleting C:\trunk\src\myfile.h  // this one's okay
deleting C:\trunk\src\res
Commit failed (details follow):
Directory 'C:\trunk\src\res' is out of date
Item '/trunk/src/res' is out of date
You have to update your working copy first.

What is a solution to this problem? Surely I'm not the first to run into this issue, but I cannot seem to find anything on google or stackoverflow. Some people suggest running a script to do it, but I'm still confused about the process. Do I need to delete my old trunk folder so that the missing files will get removed locally? Or should I diff and delete with a script?

Thanks!

Old (unclear) post: Migration to SVN, confused about deleting old files

Edit:

This is going from one snapshot to the next. I'm migrating from a different repository (StarTeam), so I didn't have anything in trunk. I just want to check in all the different snapshots and have the files which were deleted be removed as well. Isn't it a bad idea to tag if I don't have anything in trunk?

Answer 1

There's actually a Subversion script that does this for you called svn-merge-repos.pl

I'm not 100% sure you're understanding the concept of how Subversion works. Did you go through the Subversion book?

In Subversion, there are no real tags/labels or branches metadata like you find in many version control systems. Instead, you put tags and branches in their own directories. To create a branch or tag, you copy what you want to branch or tag into the directory:

# Creating a branch for 2.0 development from trunk
$ cp http://server/svn/module/trunk http://server/svn/module/branches/2.0

# Tagging my 2.0 development as 2.0.1
$ cp http://server/svn/module/branches/2.0 http://server/svn/module/tags/2.0.1

In theory, you can simply create a new branch or tag directory for each release and branch you're working on without a need for merging repositories. That's what I did when I did a StarTeam to Subversion conversion. The problem is that you lose the relationship between say revision 2.0.1 and 2.0.2 since they don't share a common history. 99% of the time, that's not really a problem, and you can always go back to the original StarTeam archive if you need anything. In a few months, no one will care.

However, if you know the relationship between branches and tags, and want to keep that information, you'll have to do the two step script I described above.

For example, you have a 2.0 branch that comes from trunk, a 2.0.1 tag, a 2.0.2 tag, and a 2.0.3 tag, you might want to do this:

• Put branch 2.0.1 release onto trunk.
• Copy trunk to branches/2.0.
• Put the next branch on trunk and copy it to its branch (use the svn-merge-repos.pl script)
• Finally, put the current trunk.
• Now go to that branches/2.0 directory and copy that to tags/2.0.1. Using the svn-merge-repos.pl script, create the 2.0.1 release on branches/2.0 and copy that to tags/2.0.2. Keep going until you get to the tip of the 2.0 branch.

That takes a lot longer to do, but it's feasible. Last time I did that, it took me about a week and a half to do the entire conversion. Fortunately, I did the trunk first and then the active release which I could do in a day. Then, worked my way back to the less active stuff.

Answer 2

I'm certainly not an expert on SVN, but I believe that you've got to issue the svn delete command for the items you want to delete upon the next commit. It's described here.

Answer 3

You should create a tag instead.
EDIT:
svn status list all changes
you can print all deleted files like this:
svn status | grep -E '^!' | awk '{print $2}' > /tmp/changes
You can do a svn delete on each file with a batch ;)

EDIT: (SVN Migration How-To)

Let's assume you have a project named projectA, and a blank SVN repository.
First, you should create a Folder structure like this:

projectA/
|-- branches
|-- tags
|-- trunk

Then import your project files.

projectA/
|-- branches
|-- tags
`-- trunk
    |-- README
    `-- src

After the import you can create a tag to "mark" the initial release:

projectA/
|-- branches
|-- tags
|   `-- release-1
`-- trunk
    |-- README
    `-- src

After this point, you should edit your files as you like. When you think all your edits are "Good", then commit.
After some commits, if you want to release, create a tag.

Trunk should always contain the up-to-date version of your code.
I highly recommend you to use TortoiseSVN on Windows if you are a rookie ;)

Answer 4

You should use svn-load-dirs.pl:

"This Perl script is designed to load a number of directories into Subversion. This is useful if you have a number of .zip's or tar.{Z,gz,bz2}'s for a particular package and want to load them into Subversion."

Basically what you do is:

• export all you tags chronologically
• create an empty repository
• use svn_load_dirs.pl to "stack" tag after tag in your subversion.

svn_load_dirs.pl creates a single revision for each tag and you can as well create a (subversion-)tag after each import. It will keep track on all deleted and added files and will perform the appropriate svn actions. This means you can explicitly start with an empty trunk

Answer 5

From your question, it looks like that you are completing misusing SVN. There is no point in deleting the entire trunk/src folder and replacing it with a new one except in case of a huge change in the code.

Instead, create a tag for the release.