git-svn ветвление: как настроить git config - PullRequest
5 голосов
/ 20 июля 2010

Несколько месяцев назад я настроил GIT с хранилищем SVN.До сих пор я использовал только svn-репозиторий, чтобы быть в курсе поставляемого приложения.Но теперь я также хочу вернуть вещи обратно.Чтобы сделать это, каждая функция, которую я собираюсь совершить, должна находиться в отдельной ветке.Я читал о том, как вы должны создать новую ветку и т. Д. Но я думаю, что неправильно настроил свой git, у меня нет информации о ветке и т. Д. Я думаю, что у меня есть только информация о транке.Вот как мой svn-репозиторий был настроен в моей конфигурации git:

[remote "origin"]
    url = url-of-git-repository
    fetch = +refs/heads/*:refs/remotes/origin/*
[svn-remote "svn"]
    url = url-of-svn-repository/trunk
    fetch = :refs/remotes/git-svn
[branch "master"]
    merge = refs/heads/master
    remote = origin
... other branch information below (these are git branches)

Теперь, как вы можете видеть, мой URL-адрес svn-remote идет прямо в транк.Я читал о добавлении этого:

branches = branches/*:refs/remotes/*

, но когда я создаю новую ветвь, она будет добавлять ее в ствол / ветки /.Когда я не добавляю строку, тогда она не знает, каково назначение ветви.

Любая идея, как решить эту проблему, не ломая существующие ветки, код и т. Д .?

приветствует, Daan

Ответы [ 2 ]

6 голосов
/ 24 мая 2011

Я считаю, что конфигурация веток относится к URL-адресу svn-remote.

Вот наша конфигурация, как она была сделана с помощью

git svn -s url-of-svn-repository/foo

(Внутри папки foo у нас нормальная структура trunk / branch / tags)

[svn-remote "svn"]
        url = url-of-svn-repository
        fetch = foo/trunk:refs/remotes/trunk
        branches = foo/branches/*:refs/remotes/*
        tags = foo/tags/*:refs/remotes/tags/*

Вы можете попробовать приспособиться к этой структуре или сделать клон git svn снова с параметром -s. Он настроит все это для вас (--standard-layout).

0 голосов
/ 14 июня 2011

Это был пост, который помог мне заставить git работать с svn над проектом, который имел очень необычную отраслевую структуру (что, как я боюсь, является нормой для компаний, использующих SVN).

http://www.dmo.ca/blog/20070608113513/

...