мерзавец-svn: отслеживание сброса для ведущего устройства

Я использую git-svn работать с репозиторием SVN. Мои рабочие копии были созданы с помощью git svn clone -s http://foo.bar/myproject так, чтобы моя рабочая копия следовала схеме каталога по умолчанию SVN (соединительная линия, теги, ответвления).

Недавно я работал над ответвлением, которое было создано с помощью git-svn branch myremotebranch и проверил использование git checkout --track -b mybranch myremotebranch. Я должен был работать от нескольких местоположений, таким образом, от ответвления I git-svn dcommit- файлы редактора к репозиторию SVN вполне регулярно.

После окончания моих изменений я переключился назад на ведущее устройство и выполнил слияние, фиксировал слияние и попробовал к dcommit успешное слияние к удаленной соединительной линии.

Кажется, как будто после слияния удаленное отслеживание для ведущего устройства переключилось на ответвление, я продолжал работать:

# git checkout master
# git merge mybranch
... (successful)
# git add .
# git commit -m '...'
# git svn dcommit
Committing to http://foo.bar/myproject/branches/myremotebranch ...
#

Есть ли способ, которым я могу обновить ведущее устройство так, чтобы он следовал remotes/trunk как перед слиянием?

Я использую мерзавца 1.7.0.5, если это - какая-либо справка.

Было бы полезно, если Вы могли бы также объяснить, почему это произошло, таким образом, я могу избежать проблемы, происходящей снова.Спасибо!

Править:

Вот мой ток .git/config:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    autocrlf = false
[svn-remote "svn"]
    url = http://foo.bar/myproject
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*
[branch "mybranch"]
    remote = .
    merge = refs/remotes/myremotebranch

Таким образом, кажется, что соединительная линия указывает на корректное место. Однако переключение на ответвление затем обратно ведущему устройству не помогает; git svn dcommit в ведущем устройстве все еще пытается продвинуть к myremotebranch.

28
задан Phillip B Oldham 17 May 2010 в 08:13
поделиться

3 ответа

Когда в стволе нет изменений, git выполняет быстрое слияние и просто устанавливает локальную «главную» ветвь на фиксацию в вашей ветке. Git-svn не знает, как фиксировать слияния с быстрой перемоткой назад в ствол, на самом деле он думает, что "master" теперь указывает на ветку svn.

Чтобы обойти это, используйте git merge --no-ff при слиянии. Это заставит git создать коммит слияния, который затем можно будет передать svn.

22
ответ дан 28 November 2019 в 03:20
поделиться

Если вы еще не сделали никаких коммитов на главном сервере, это означает, что git merge mybranch был перемоткой вперед: master HEAD просто переместите к mybranch HEAD .

Это может объяснить, почему git svn dcommit перенес ваши изменения в SVN mybranch .
Он должен:

  • сначала обновить соответствующую ветвь SVN последними коммитами Git mybranch , еще не зафиксированными,
  • записать слияние в магистраль на стороне SVN
  • , а затем переустановить мастер на сторона Git (нечего делать, уже есть).

Я не думаю, что мастер не менял свою ссылку, но если у вас есть сомнения (и ваш рабочий каталог чист), вы можете (если мастер в настоящее время извлечен):

git reset --hard remotes/trunk
5
ответ дан 28 November 2019 в 03:20
поделиться

В общем, вы не должны использовать git merge с git svn , потому что svn, даже с ветвями, не поддерживает такой вид слияния отслеживание того, что делает git. Когда вам нужно объединить ветку, я добился наибольшего успеха (по крайней мере, с недавним svn), выполнив простой процесс проверки / слияния svn, а затем использовал git svn rebase для обновления моих репозиториев git-svn. Это сохраняет собственные метаданные svn для отслеживания слияния, которые (AFAIK) git-svn полностью игнорирует.

Я не совсем уверен, в каком состоянии находится ваш svn-репозиторий - я бы проверил, чтобы dcommit слияния выполнял то, что вы хотели, в магистрали. Даже если бы это было так, Готов поспорить, если вы посмотрите содержимое файлов refs / Heads / master и refs / remotes / trunk в вашем репозитории, то увидите, что они сейчас разные . Если это так, я бы (без локальных изменений) сделал бы git-svn fetch , а затем git branch -f master remotes / trunk; git reset --hard master для повторной синхронизации ветки git с веткой отслеживания git-svn.Если у вас есть локальные изменения, вам нужно будет выполнить фиксацию и сделать что-то вроде git rebase master ^ 4 --onto remotes / trunk , где 4 - количество коммитов, которые необходимо сохранить. В качестве альтернативы, если все они не зафиксированы, сначала спрячьте их с помощью git stash .

В противном случае вы всегда можете получить все в svn и просто стереть репо и получить новую проверку.

4
ответ дан 28 November 2019 в 03:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: