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
qazwart_at_gmail.com
Received on 2010-11-11 15:58:12 CET