12

I have an SVN repository structure like below. We are using multiple levels under branches for various release maintenance branches, plus a directory for feature branches.

git-svn init seems to work with a single --branches argument, i.e. it seems to expect all of the branches to be in a single location.

trunk
branches
  1.1
    1.2.1
    1.2.2
  1.2
    1.2.1
    1.2.2
    1.2.3
  features
    feature1
    feature2

Any ideas on how to handle this?

Thanks

CaptainPicard
  • 953
  • 8
  • 8
  • Probably this has changed since 2008, but nowadays "you can specify more than one ``--tags`` and/or ``--branches`` options, in case your Subversion repository places tags or branches under multiple paths." (quoted from ``man git svn branch``) – steffen Aug 06 '13 at 07:45

4 Answers4

13

In your config file, set the svn-remotes section to something like:

[svn-remote "svn"]
    url = svn://svnserver/repo
    fetch = trunk:refs/remotes/trunk
    branches = branches/*/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*

This should let you grab the nested branches.

Arthur Ulfeldt
  • 90,827
  • 27
  • 201
  • 284
Greg
  • 2,163
  • 1
  • 18
  • 40
  • This completely solves my problem. I've been using this for a while now. It did require later versions of git and/or svn, sorry I don't know the particulars but am currently using git 1.6.2.5 and svn 1.5.1 and it works fine with that. – CaptainPicard Aug 04 '09 at 13:12
  • 2
    you need to delete `.git/svn/.metadata` and git a `git svn fetch` to refresh the branch/tag list – rcoup May 25 '11 at 23:45
  • 3
    What happens if you have branch/a/thisname and branch/b/thisname? Doesn't it explode? – android.weasel Dec 18 '12 at 14:46
1

By convention, Subversion branches all live in a single 'branches' path in the Subversion repository, so I'm not surprised that git-svn makes this assumption.

I'd suggest the following (note, you may lose some history in this operation):

  1. Flatten the Subversion branches paths, using a naming convention to keep unique identities and the idea of the current structure.
  2. Perform git-svn
  3. Move things around in the git repository to conform with your practices.

The danger of losing history depends on how well git-svn follows copy operations from dissimilar paths. I've run into this problem migrating subversion repositories (1.4-ish) recently.

Ken Gentle
  • 13,277
  • 2
  • 41
  • 49
0

Would it be feasible to create a git repo for each of the branch subdirectories?

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • And then, what, merge them all together and create the proper branches/tags after the fact? There's got to be a simpler solution – Peter Burns Nov 05 '08 at 23:58
  • The simplest solution would be to flatten your branches directories into a single directory, which would not only make `git` happy, but also bring your repo in line with the `svn` conventions. I'm not sure how practical that is in your case. – Hank Gay Nov 06 '08 at 09:58
0

You could add multiple git svn remotes for each of the branches, or possibly each of the directories of branches. The initial git svn fetch would take forever, but from what I understand it should work.

Peter Burns
  • 44,401
  • 7
  • 38
  • 56