Subversion issue after cvs2svn

Question

I am using eclipse / subclipse for development. I also have the TortoiseSVN client.

I am trying to move a CVS repository. The old CVS repository had a single project. We want to reogranize as several of the projects have their own development streams, and should be managed separately.

I ran the standard full move of the repository using cvs2svn, and had no issues.

I want to restructure the projects in the subversion repository, so after the cvs2svn, I attempted to do an svn move and did the restructuring. I was able to successfully do the move, again no issues.

I check out the project in eclipse, and then choose a file in one of the MOVED projects. It seemingly doesn't matter which project. If I do an Update Version in eclipse, and choose a version in the file's history to update to, the file is deleted from my filesystem, but the older version never comes down. The file is simply gone.

I have the same issue using TortoiseSVN, so I assume that it is not a subclipse issue.

The interesting thing is that if I do an SVN MOVE of a project BACK to its original location where it was initially converted to, and follow the same steps, I don't have any issues, the Update Version works as expected.

So, to my question(s): 1. Did I do something wrong during the cvs2svn move that would preclude me from successfully reorganizing my subversion repository? 2. Is there a better way to do what I am trying to do?

Answer 1

1. No, you didn't do anything wrong
2. Yes. You should reorganize your CVS Repository before you import it via cvs2svn

Reason for this symptom:

You always need to check out a folder. If you update to a previous version, this folder may not exist(the folder was moved) then Subversion will delete its contents. Renaming in Subversion is always implemented as remove and add. So you have a thin connection between files, but it is merely for history of this file. If you want to see the new layout you need to checkout a folder which contains both: target and source folder. Than you will be able to "see" the move of this folder, however if you only have one of the folders in your checkout, the folder will just vanish and you need to checkout a different URL(either target or source).

So It is easier to restructure your projects in CVS and then migrate. Disadvantage: You will not have any history of your restructuring and you are not able to build/compile previous versions (which were created in CVS).

Answer 2

I agree with Peter Parker that it is easy and preferable to reorganize the projects in CVS before the converting to Subversion, if what you want to do is reorganize folders and files within individual projects.

But if you want to reorganize the layout of the projects themselves (i.e., where one project lives relative to another), you can do this easily as part of the cvs2svn conversion. When you do a multiproject conversion, you can specify where cvs2svn should place the trunk, branches, and tags directories for each of the projects. Simply place them according to your desired new project organization and then you should have no problem working with the repository using any of the usual tools.

Answer 3

Where I work, we've decided to move the files in SVN after the import from CVS. CVS has limited history capabilities with moving, while the SVN repository can be "rolled back" to see what it looked like at any time. Again, by doing this, the decision was made that retaining a history of all the changes and moves was more important.

What we've done is move the module from CVS into SVN as is. Then, using the repository browser, move all the files as needed, before a check-out.

Now, this doesn't address your problem when you update an individual file to an older version that it may disappear. We've decided to live with this, because we're trying to move away from a file-centric view of the repository (CVS) to a snapshot-based one. So if we need to go back to an older version, we update the whole project. If you're just looking at the diff history, that works well from TortoiseSVN when we allow moves/renames.