Как правильно работать с (разными) удаленными репозиториями SVN через GIT? - PullRequest
1 голос
/ 19 января 2011

Среда:

  • Близлежащий SVN-репозиторий с именем svn + ssh: // yourserver / svn / prj
  • Внешний SVN-репозиторий с именем svn + ssh: // itsserver /svn / prj
  • Локальный репозиторий git, который называется "myrep" и представляет собой клон git-svn ближайшего
    • , созданный с: git svn clone -R nearbysvn -s svn+ssh://yourserver/svn/prj, так что есть ствол и некоторые ветви (оба разветвлены / скопированы из транка r3.
$ git branch -a
* master
 remotes/b1
 remotes/b2
 remotes/trunk

Вот и мы.

Простые изменения, сделанные в моем мастере (который является ответвлением от пульта дистанционного управления)./ trunk) добавляются, затем фиксируются, затем «проталкиваются» в SVN через git svn dcommit.

Пока все хорошо. Дерево теперь выглядит так:

$ git log --graph --oneline --all
* 1e6277f change 3 in b2
* 7623755 two new branches
| * 7901fad change3 in b1
| * e83f135 two new branches
|/  
| * 6fac7ad change 3
| * 5858495 new file test3
| * 4cdf2ed change2
| * 511ed7a change1
|/  
* d5c68ab init

Заключение1:

git svn dcommit отправляет все изменения, сделанные в моей локальной ветке master, в SVN удаленного / транкового канала, а затем перебазирует его. Вывод и дерево выглядят так:

$ git add test

$ git ci
[master 8a03901] modified test via git for SVN trunk
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git svn dcommit
Committing to svn+ssh://yourserver/svn/prj/trunk ...
    M   test
Committed r9
    M   test
r9 = 542eb78f841fc1a4d12f4a72f68e40e3069f3309 (refs/remotes/trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk

$ git log --graph --oneline --all
* 542eb78 modified test via git for SVN trunk
* 6fac7ad change 3
* 5858495 new file test3
* 4cdf2ed change2
* 511ed7a change1
| * 1e6277f change 3 in b2
| * 7623755 two new branches
|/  
| * 7901fad change3 in b1
| * e83f135 two new branches
|/  
* d5c68ab init

Вопрос 1:

  • почему init является родителем для b1 и b2?
  • почему мой мастер такой же, как дерево "init", если оно не является "веткой"с удаленного?Состояние слияния все еще «неотключено», потому что была сделана только перебазировка

Вопрос 2:

Как правильно / лучше всего исправить некоторые изменения на пульте / b1

по-моему: создайте локальную ветку myb1 с git checkout -b myb1 remotes/b1, затем $ git diff master^..master | patch -p1, затем добавьте, ci, dcommit

Вопрос 3:

как я могу получить информацию о моих ветках наот каких удаленных путей они принадлежат / из которых разветвляются?Конфиг не говорит мне ничего об этом:

$ git config --get-regexp svn-remote
svn-remote.nearbysvn.url svn+ssh://yourserver/svn/prj
svn-remote.nearbysvn.fetch trunk:refs/remotes/trunk
svn-remote.nearbysvn.branches branches/<em>:refs/remotes/</em>
svn-remote.nearbysvn.tags tags/<em>:refs/remotes/tags/</em>

Вопрос 4:

Это несколько сложнее: Второй (внешний) SVN теперь является «дубликатом» первогос одним исключением: внешний может быть использован и другими.В настоящее время все изменения, внесенные в «рядом», должны быть сделаны снова во внешнем (исправление файлов во второй рабочей копии и т. Д. ...

Если это удаление SVN теперь является вторым удаленным репозиторием SVN,Каков наилучший способ «оптимизировать» это с помощью слияний с помощью git?

Да, есть некоторые замечательные парни, которые будут использовать BeyondCompare и т. д. (см. Как сравнить источник в репозитории Git с источником в репозитории SVN). Но это НЕ мой любимый способ "слияния"

Я предлагаю мне: * локальные ветки, такие как myb1, master, master2 *, это ветки / ветки для моей работы, такие как master-taskX (git checkout -b master-taskX) * тогда я мог бы использовать merge, чтобы вернуть свои изменения мастеру, а затем отменить их ??

Я буду рад получить известие от некоторых экспертов git-svn;)

С уважением, ~ Марсель

Приложение:

К вашему сведению: вот исходная история SVN для "поблизости":

------------------------------------------------------------------------
r8 | konqi | 2011-01-19 17:48:51 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   M /branches/b2/test3

change 3 in b2

------------------------------------------------------------------------
r7 | konqi | 2011-01-19 17:48:42 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   M /branches/b1/test3

change3 in b1

------------------------------------------------------------------------
r6 | konqi | 2011-01-19 17:46:07 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   M /trunk/test3

change 3

------------------------------------------------------------------------
r5 | konqi | 2011-01-19 17:36:13 +0100 (Mi, 19 Jan 2011) | 3 lines
Changed paths:
   A /branches/b1 (from /trunk:1)
   R /branches/b1/test (from /trunk/test:2)
   R /branches/b1/test2 (from /trunk/test2:3)
   A /branches/b1/test3 (from /trunk/test3:4)
   A /branches/b2 (from /trunk:1)
   R /branches/b2/test (from /trunk/test:2)
   R /branches/b2/test2 (from /trunk/test2:3)
   A /branches/b2/test3 (from /trunk/test3:4)

two new branches


------------------------------------------------------------------------
r4 | konqi | 2011-01-19 17:30:05 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   A /trunk/test3

new file test3

------------------------------------------------------------------------
r3 | konqi | 2011-01-19 17:28:46 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   M /trunk/test2

change2

------------------------------------------------------------------------
r2 | konqi | 2011-01-19 17:28:34 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   M /trunk/test

change1

------------------------------------------------------------------------
r1 | konqi | 2011-01-19 17:28:10 +0100 (Mi, 19 Jan 2011) | 2 lines
Changed paths:
   A /branches
   A /tags
   A /trunk
   A /trunk/test
   A /trunk/test2

init

------------------------------------------------------------------------

Ответы [ 2 ]

0 голосов
/ 20 января 2011
  • почему init является родителем для b1 и b2?
    • Поскольку в истории svn init создает папку 'веток', а git-svn рассматривает ее как родителя всех коммитов ветви.В конце концов, это просто соглашение и не особенно важно для какой-либо функциональности.
  • почему мой мастер такой же, как дерево "init", если это не "ветвь" изудаленный?
    • Это ветка с пульта, но коммиты git не являются частью веток, это не то, как думает git.Для git «ветвь» - это указатель на коммит, который подразумевает все родительские коммиты.Сами коммиты не знают или не заботятся, в какую ветвь (-и) они входят.
  • Статус слияния все еще "не объединен", потому что была сделана только перебазировка
    • (не знаю, о чем вы здесь говорите)

Вопрос 2:

  • Какой правильный / лучший способ исправить некоторые измененияна пульт / b1
    • Если вы не выполняете полное слияние, попробуйте git cherry-pick (см. git help cherry-pick);это более или менее простой и надежный способ сделать то, что вы уже делаете

Вопрос 3:

  • как я могу получить информацию омои ветки, к каким удаленным путям они принадлежат?
    • Вы можете проверить их и запустить git svn info или использовать git log и grep для строки svn в нижней части сообщения фиксации, в которой перечислены путь и версия источника.Последний является авторитетным источником для git-svn, откуда взялись svn коммиты.

Вопрос 4:

  • Это немного сложнее: Второй (внешний) SVN теперь является «дубликатом» первого, за одним исключением: внешний может использоваться и другими.В настоящее время все изменения, внесенные в «рядом», должны быть снова сделаны во внешнем (исправление файлов во второй рабочей копии и т. Д. ...

    Если это удалить SVN теперь второй удаленный репозиторий SVN,Как лучше "оптимизировать" это с помощью слияний с помощью git?

    Да, есть некоторые замечательные парни, которые будут использовать BeyondCompare и т. д. (см. Как сравнить источник в репозитории Git с источником в репозитории SVN).это НЕ мой любимый способ «слияния»

    Я предлагаю, чтобы мне понадобились: * локальные ветки, такие как myb1, master, master2 * для этой работы, такие как master-taskX (git checkout -b master-taskX) * тогда я мог бы использовать merge, чтобы вернуть свои изменения в master, а затем dcommit их ??

    • У меня было бы два репозитория git на одной машине, один (назовем их A и B) установите для отслеживания каждого репозитория SVN. Сделайте вашу разработку на A, установите для отслеживания ближайшего репо. Пусть B зарегистрирует A как обычный git «remote» (git remote add / path / to / repo / A) после того, как вы выполните git svnклон. Однажды тыесли ваши коммиты готовы к dcommit на A, используйте git fetch -f в B, чтобы привести их туда.Тогда git svn dcommit в A;в B используйте что-то вроде git checkout -b temp A/master; git rebase --onto trunk HEAD^; git svn dcommit; git checkout master; git branch -D temp, чтобы зафиксировать изменения в репо B. Чтобы сделать несколько оборотов, вы должны отрегулировать количество каратов в команде rebase.

ПримечаниеВ общем, по моему опыту, git merge не очень хорошо работает с git-svn, поэтому вы, вероятно, захотите придерживаться техник, подобных приведенным выше, которые не создают коммитов с двумя родителями в истории git.

0 голосов
/ 20 января 2011

Я бы сделал 2 отдельных репозитория git для 2 репозиториев svn.Затем координируйте изменения путем перебазирования и т. Д. В одном из репозиториев Git.

...