It's a little late for you, but I've found that sometimes it is best to start "clean" and give up your old history. Just keep your old repository around if you need this information.
There are many times I've moved a group to Subversion, and we simply copied over the end points of branches, and relevant tags. Wholesale conversion simply doesn't work out much of the time. The problem with wholesale conversion is that you've changed your tools around and the way you do your work. For example, your old build scripts probably no longer work because they were made to work with your old system. Like you have, I've seen sites where old build tools required strange repository layouts that no longer make sense under Subversion. The first time I realized this was a conversion from StarTeam to ClearCase. There were no automated tools for the conversion, and StarTeam was practically impossible to write a script for. Commands were limited, and each command needed the entire login information in order to work. In the end, we decided our StarTeam repository would still be available, and we would simply convert over just a few branches and tags that we needed. This suddenly freed me to rearrange the repository. We got rid of the cruft that had built up over 7 years of development, and arranged things in a more logical layout. At first, the developers were unhappy because they would have to go into StarTeam to look up history, but then they realized they rarely did that anyway. After a while, the developers were happier with this new arrangement. You haven't mentioned your IDE tool, and why your repository is in this strange layout, or why is it setup with so many files in one directory structure and why files you need are scattered all over the place. So, it's a bit difficult to understand. It could be that you have some sort of proprietary software project that requires this structure -- maybe some sort of document repository front end. If your repository REALLY needs to be setup this way, Subversion isn't the tool for you. Subversion is highly optimized for directory checkout structure. Its revisioning system is based upon it. Its tools assume this. You'll be better off with something that allows each and every file to be independently versioned like CVS did. Is your only choice with your IDE Subversion? Right now, you have three choices: 1). Restructure your repository to make using Subversion efficient. 2). Switching to another version control system that better matches what you want. 3). Keep what you have and try to use Subversion in a way that's not very efficient, and will be hard for new employees to support. The last option will take more work in the long run, and in the end, you'll end up with a bunch of unhappy users. -- David Weintraub qazw...@gmail.com