Subversion issue after cvs2svn
I am using eclipse / subclipse for development. I also have a TortoiseSVN client.
I am trying to move a CVS repository. The old CVS repository had one project. We want to refocus as some of the projects have their own development flows and need to be managed separately.
I followed the standard full repository turn with cvs2svn and had no problem.
I want to restructure projects in a subversion repository, so after cvs2svn I tried to svn move and did the restructuring. I was able to successfully move, again no problem.
I check out a project in eclipse and then select a file in one of the moved projects. It doesn't seem to matter which project. If I do an updated version in eclipse and select a version in the file history to update, the file is removed from my filesystem, but the older version never comes down. The file just went away.
I have the same problem as TortoiseSVN, so I'm guessing this is not a subquery problem.
Interestingly, if I make the svn move
project back to its original location where it was originally converted, and follow the same steps, I have no problem, the update version works as expected.
So, to my question (s):
- I did something wrong while moving cvs2svn that would prevent me from successfully refactoring my subversion repository?
- Is there a better way to do what I am trying to do?
a source to share
Where I work, we decided to migrate the files to SVN after importing from CVS. CVS has limited history when moving, whereas the SVN repository can be "rolled back" to see what it looks like at any time. Again, having done this, it was decided that keeping the history of all changes and moves was more important.
We have made the transfer of the module from CVS to SVN as it is. Then, using the repository browser, move all files as needed before checkout.
Now, this does not address your issue when updating an individual file to an older version, which may disappear. We decided to live with it because we are trying to move away from a file-based repository view (CVS) to a snapshot-based view. Therefore, if we need to revert to an older version, we will update the entire project. If you're just looking at the history of differences, this works well with TortoiseSVN when we enable move / rename.
a source to share
- No, you haven't done anything wrong.
- Yes. You have to refactor your CVS repository before which you import via cvs2svn
The reason for this symptom:
You always need to check the folder. If you are upgrading to a previous version, this folder may not exist (the folder has been moved), then Subversion will delete its contents. Renaming in Subversion is always done as a delete and add. So you have a subtle relationship between files, but that's just the history of that file. If you want to see the new layout, you need to check the folder containing both the target and source folders. Than you will be able to "see" the movement of that folder, however, if you only have one of the folders in your control, the folder will disappear and you will need to check a different url (target or source).
This makes it easier to restructure your projects in CVS and then migrate. Disadvantage: you won't have a history of your restructuring, and you won't be able to build / compile previous versions (which were created in CVS).
a source to share
I agree with Peter Parker that it would be easier and preferable to reorganize projects in CVS before converting to Subversion if you want to reorganize folders and files within separate projects.
But if you want to refactor the layout of the projects themselves (i.e. where one project lives relative to the other), you can do so easily as part of the cvs2svn conversion. When you convert the multiprojects , you can specify where cvs2svn should place the trunk, branch, and tag directories for each project. Just 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.
a source to share