0

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?

Community
  • 1
  • 1
Jordan
  • 9,014
  • 8
  • 37
  • 47

5 Answers5

3

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.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • Hi David, thanks for the help. Yep, I'm aware of the svn basics and how branching/tagging/copying works. I do indeed want to keep some history rather than just committing each to their own tag. The problem I'm having is that I started with the OLDEST code and put that snapshot directly onto trunk. I was hoping to do this in chronological order. Should I instead put everything into their own tags and then merge them into trunk one at a time? – Jordan Dec 20 '11 at 17:55
  • For simplicity, say I have versions 1.0, 2.0, 3.0, 4.0, 5.0...10.0. R1.0 has some files which were deleted before going to R2.0, etc. Do I commit each of them into their own tags such as /tags/R1.0, /tags/R2.0, /tags/R3.0 and then merge into /trunk/ after they're all there? Will that solve my missing/deleted file problem? Remember that I want to remove any files that don't exist anymore since these are snapshots already in chronological order. And it's only one repository that I'm migrating, just multiple snapshots/checkouts from it for each release version. Thanks! – Jordan Dec 20 '11 at 17:58
  • You want to put version 1.0 onto trunk, create a tags/1.0 directory, then use svn-merge-repos.pl to add in version 2.0 on top of trunk, commit it, then copy that to tags/2.0, etc. If a file isn't in version 2.0, but is in version 1.0, you need to run `svn delete`. If it's in version 2.0, but not 1.0, you need to run `svn add`. – David W. Dec 21 '11 at 05:50
  • Ah yeah, okay. So it's essentially the same thing as blowing away the folders and copying the new ones over and then running Add/Commit then. I still need to find a way to delete the files which were in 1.0 but not in 2.0. It turns out that tortoiseSVN is fine with deleting files, but not folders (presumably since the folder gets set to "modified" when a file within it gets deleted". Maybe I'll just diff to see which highest level folders differ and then delete them. – Jordan Dec 21 '11 at 16:28
  • @Jordan - use the svn-merge-repos.pl script. I gave you a link to it. This script takes care of deleted and added files and folders for you. – David W. Dec 21 '11 at 19:13
1

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.

Taylor Price
  • 622
  • 1
  • 8
  • 21
  • I have 1800 files which were deleted from one release to the next. I can't possibly go through and manually issue svn delete on each of them. Isn't there some sort of batch deletion? – Jordan Dec 20 '11 at 17:27
  • 1
    If they are all in the same folder you may svn delete the entire folder. – Victor Stafusa - BozoNaCadeia Dec 20 '11 at 17:34
  • @Jordan I understand that you've got a lot of files to delete. If the files are already in the SVN repo, then I would suggest writing a script to issue an svn delete command on everything (files OR directories as Victor pointed out) that needs to be deleted (as you mention was suggested earlier). However, given that you're migrating, have you already checked this code into SVN? If not, why not create an empty repo and filter out the files you don't need before adding to the repo? – Taylor Price Dec 20 '11 at 17:35
  • @Taylor Price: Thanks for the help. They are NOT in the same folder, but instead scattered across many subfolders which still have good files. If I were to write the script, I would still need to delete everything and then copy/add so that SVN knows that files are missing, don't I? Otherwise the deleted files will still be there if I just copy on the files which changed for the newer revision. How do I filter out the files that I don't need? – Jordan Dec 20 '11 at 17:40
  • @Jordan You're welcome. Before we take this line of thought further, it looks like David W.'s answer will help you more than mine will. – Taylor Price Dec 20 '11 at 18:29
  • @Taylor Price: Yep, I did, but I'm confused on that one as well lol. Perhaps we should continue the discussion under that post though? – Jordan Dec 20 '11 at 19:00
1

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 ;)

kbdjockey
  • 891
  • 6
  • 8
  • I'm migrating code, meaning that I don't currently have anything in svn. Or should I just import/add everything directly to the /tags folder without having anything on trunk? That seems like a bad idea... Even still, how would I get it in trunk after? Or would I just check in the latest release to trunk after adding everything else to trunk? – Jordan Dec 20 '11 at 17:26
  • If you just migrating, your SVN repo should empty. you should create folders trunk, branches, and tags. Then import all your existing code in the trunk folder. – kbdjockey Dec 20 '11 at 17:31
  • Yes, I did that for Rev1. But what do I do with Rev2 where files that used to be in Rev1 were deleted for Rev2? I'm trying to commit that into trunk and then tag it as well, but it's causing problems with the deleted files/folders. – Jordan Dec 20 '11 at 17:35
  • Ok, so you don't understand how to use SVN obviously. I edit my answer to explain you "all" – kbdjockey Dec 20 '11 at 17:37
  • Yes, I already did all of that. I already checked in code for release-1 into trunk, and then tagged it as release-1. Now I have to also add/commit release-2, but some files which were in release-1 are not in release-2 and have already been deleted. How do I commit the entire release-2 snapshot? – Jordan Dec 20 '11 at 17:45
  • For deleting a file you simply do: `svn delete file1; svn commit` – kbdjockey Dec 20 '11 at 17:52
  • Yes, 1800 times... That's my question. How do I delete large amounts of files? – Jordan Dec 20 '11 at 17:59
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/6016/discussion-between-jordan-and-kbdjockey) – Jordan Dec 20 '11 at 18:15
1

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

Peter Parker
  • 29,093
  • 5
  • 52
  • 80
0

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.

Victor Stafusa - BozoNaCadeia
  • 13,995
  • 13
  • 56
  • 72
  • I'm migrating code, meaning that I don't currently have anything in svn. Or should I just import/add everything directly to the /tags folder without having anything on trunk? That seems like a bad idea... Even still, how would I get it in trunk after? Or would I just check in the latest release to trunk after adding everything else to trunk? – Jordan Dec 20 '11 at 17:26
  • If your trunk is empty, add everything there. Commit. Create a tag. If it is not empty, do a svn delete in whatever you don't need. Deleting them locally will just mess up your working copy. Do that even if it is 1800 files. – Victor Stafusa - BozoNaCadeia Dec 20 '11 at 17:31
  • Yes, I did that for Rev1. But what do I do with Rev2 where files that used to be in Rev1 were deleted for Rev2? I'm trying to commit that into trunk and then tag it as well, but it's causing problems with the deleted files/folders. Edit: How do I svn delete 1800 files? Manually one at a time? For 10 revisions? It will take me a month.... – Jordan Dec 20 '11 at 17:34
  • If you are using TortoiseSVN, you may re-add the files and select the unwanted files and folders in Windows Explorer, and then select Delete from the Tortoise SVN menu. One of the worst things to do in SVN is to mess deleted files, and looks like that this bited you. – Victor Stafusa - BozoNaCadeia Dec 20 '11 at 17:44
  • The files which need to be deleted are all over the place in hundreds of different subfolders, and there are 1800 of them. And I'm adding 10 snapshots, so that's 10x1800=18000 files to manually delete. That is not a feasable solution. – Jordan Dec 20 '11 at 18:01
  • Revisions are incremental. I.E, get revision 567, change some files. Commit. You will get revision 568. Change some files again, commit. You will get 569, and so one. The changes should be small. If you are using SVN to dump a lot of code from somewhere else and completing deleting the old one, them you completelly missed the point of SVN and are horribly misusing it. – Victor Stafusa - BozoNaCadeia Dec 20 '11 at 18:05
  • Please read my posts. I am DUMPING entire revisions into SVN from StarTeam, since I'm attempting to move from StarTeam to SVN. I'm trying to get STARTED with SVN, meaning I need to dump large amounts of code into it, but I'm trying to keep some file history. Hence the snapshots of past releases. – Jordan Dec 20 '11 at 18:10