3

I had a boss, past-tense, who decided to put svn branches in the same folder as trunk. Normally, this wouldn't affect me that much but since I'm using git-svn things are going so well. After I did a fetch it created a folder for each branch in my root folder so I have three folders, drupal, trunk, and client. The drupal folder is git's master branch, client and trunk are the svn branches.

Merging and committing works great, in fact everything git related is working superb. However dcommit is totally hosed, it's trying to commit a folder called client and one called trunk. I can't even imagine what havoc this would cause for svn later on.

So my question is, what have I done wrong in my .git/config and is there anything I can do to fix this or am I going to have to suffer and go back to using svn?

Please don't make me go back. I don't think I can take it anymore. Bastard boss knows how to leave a legacy. 

[svn-remote "svn"]
        url = https://svn.mydomain.com/svn/project_name
        fetch = trunk:refs/remotes/trunk
        branches = *:refs/remotes/*
        tags = tags/*:refs/remotes/tags/*

Normally the branches line would look like this (when using --stdlayout): 

branches = branches/*:refs/remotes/branches/*

ls output is thus:

$ ls
client/ docs/ drupal/ sql/ trunk/

git -a output:

* master
  trunk
  remotes/git-svn
  remotes/trunk
Chuck Vose
  • 4,560
  • 24
  • 31
  • Has something changed? Has dcommit ever worked? – dlamotte May 04 '10 at 23:04
  • Yes, I used to be using stdlayout and it worked great. But I needed to start talking to this client branch so I had to change the .git/config – Chuck Vose May 04 '10 at 23:05
  • @chuck what did it look like before the change and after the change? – dlamotte May 04 '10 at 23:06
  • the branches line looked like the second code sample. I think the problem is that it's assuming that trunk is a branch since the * is globbing all directories within /. That also means that if we had tags those would also be considered branches. Normally it seems the branches line would only select every directory within the branches folder. – Chuck Vose May 04 '10 at 23:10
  • @chuck what is the output of `git branch -a`? – dlamotte May 04 '10 at 23:11
  • * master trunk remotes/git-svn remotes/trunk – Chuck Vose May 04 '10 at 23:12

2 Answers2

2

I think you broke your .git/config when you changed:

branches = branches/*:refs/remotes/*

To

branches = *:refs/remotes/*

Change your .git/config back to what you had normally. Then add a new remote (which I discovered from this page, http://www.dmo.ca/blog/20070608113513/) similar to this format, but replaced with the info for your server:

[svn-remote "svn34"]
    url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
    fetch = :refs/remotes/git-svn-3.4

Please notice the difference of adding a new "remote" to track a new branch. Your current remote cannot be used to track a different branch (as it would seem from the git-svn docs).

dlamotte
  • 6,145
  • 4
  • 31
  • 40
  • For some reason my boss didn't put branches in a branches folder, he just slapped them next to trunk in the hierarchy. So the stdlayout .git/config doesn't work without doing this. – Chuck Vose May 04 '10 at 23:16
  • This is sorta subtly the answer. Turns out it's okay to have two fetch lines. So I set branches back to what it should be and added a second fetch line so client is a little bit like trunk. Git treats it really nicely and all seems to be well. Thanks for all the advice! – Chuck Vose May 05 '10 at 00:01
1

If you don't mind editing .git/config every time a branch is added, you can use glob set syntax (http://www.kernel.org/pub/software/scm/git/docs/git-svn.html#_configuration):

fetch = trunk:refs/remotes/trunk
branches = {client,drupal}:refs/remotes/*
Max Nanasy
  • 5,871
  • 7
  • 33
  • 38