Re: Fixing branches from a (really messed up) subversion repository

On Tue, Jun 15, 2010 at 16:26, Joshua Shrader [off-list ref] wrote:

I've finally convinced my project to switch to Git...  However, when
my project first began, the people responsible for branching/tagging
were fairly unfamiliar with standard procedures.  As such, the
beginnings of our repository look a little something like this:

.
`----project
    |
    `branch1
    |          |
    |          `----project
    |                        `src
    `branch2
    |          |
    |          `----project
    |                        `src
    `src

That is, the branches were essentially inside the trunk.  In order to
check out the "mainline" of development, you also got all of the
branches.  After a few branches, they realized that this was a
problem, and someone found out about the trunk/branches/tags paradigm.
 Our branches were svn mv'd to separate directories under "branches",
and all was well.  Now everything looked like a sane version control
repository.

Now, we want to import this into Git.  I tried git svn import
--stdlayout..., but this just stalled.  I'm assuming because the first
version didn't have a trunk/branches/tags structure.  So, I had to
import it leaving off the --stdlayout option.  Is there any way to
manually fix this in Git?  After the import is complete, my master
branch will have a trunk, branches, and tags directory in it.  Can I
create real branches out of the directories under the branches
directory and then remove them from master?

Any help is greatly appreciated.  I've been hoping for a while that
we'd switch to Git, and I don't want this to hang us up.

I have the same problem on another project, and after looking at the
components involved it seems that the easiest way is to filter the SVN
dump, then import it into Git.

It's quite easy to write a filter with SVN::Dump that does this,
i.e. just do a few string replacements on the paths before a given
revision, and drop the revision where you moved things.

A lot easier than convincing git-svn to do what you want, anyway.