Git Ошибка Svn dcommit - перезапустите фиксацию

На прошлой неделе я сделал ряд изменений в своем местном филиале, прежде чем покинуть город на выходные. Сегодня утром я захотел dcommit все эти изменения в репозитории компании Svn, но я получаю конфликт слияния в одном файле:

Объединить конфликт во время фиксации: ваш файл или каталог "build.properties.sample", вероятно, устарел: ресурс версии не соответствует ресурсу транзакции. Либо запрошенный ресурс версии устарел (нуждается в обновлении), либо запрашиваемый ресурс версии новее, чем корень транзакции (перезапустите фиксацию).

Я точно не знаю, почему я получаю это, но прежде чем пытаться выполнить dcommit, я сделал git svn rebase. Это "переписало" мои коммиты. Чтобы оправиться от этого, я сделал git reset --hard HEAD @{1}. Теперь моя рабочая копия, кажется, там, где я ее ожидаю, но я понятия не имею, как преодолеть конфликт слияния; на самом деле нет никакого конфликта для решения, которое я могу найти.

Любые мысли будут оценены.

EDIT: Просто хочу указать, что я работаю локально. У меня есть локальная ветвь для соединительной линии, которая ссылается на svn/trunk (удаленная ветка). Вся моя работа была выполнена на местном сундуке:

$ git branch
  maint-1.0.x
  master
  * trunk
$ git branch -r
  svn/maintenance/my-project-1.0.0
  svn/trunk

Аналогично, git log в настоящее время показывает 10 коммитов на моей локальной соединительной линии с момента последнего фиксации с идентификатором Svn.

Надеюсь, это ответит на несколько вопросов.

Еще раз спасибо.

Ответ 1

Вы должны создать локальную ветвь и выполнить эту работу, а затем, когда вы вернетесь, вы обновите мастер, переустановите на локальную ветвь, слейте обратно в master, а затем dcommit.

Итак, я попробую скопировать изменения, чтобы поддержать их.

Создайте локальную ветку из точки синхронизации svn, объедините свои изменения там. Затем отмените изменения в главной ветки, извлеките, переустановите ветвь, слейте из локальной ветки, исправьте любые конфликты, затем dcommit.

$ git checkout -b backup    # create a local backup branch with all your work
$ git checkout master   
$ git checkout -b backup2   # 2nd copy just to be safe
$ git checkout master
$ git reset --hard <this is the revision of the last svn-id> # clean up master to make the svn merge easier
$ git svn fetch    # this should update to the current version on the svn server
$ git rebase master backup  # may get a conflict here, fix and commit
... # after conflict is fixed and commited
$ git checkout master 
$ git merge backup --ff  # merge in your local commits
$ git svn dcommit        # push back to the svn

Вы можете получить дополнительную информацию здесь

Другой ответ, который может вас заинтересовать.

git -svn статьи рабочего процесса

Статья

Ответ 2

С большой благодарностью за VonC и sfassen необычайное терпение со мной, вид решения работал сам. Я не знаю, как и почему, но, возможно, моя первоначальная перебаза не сработала. Чтобы исправить это, я снова перестал. Из моей локальной ветки:

$ git co -b backup  # backup the commits to my local trunk
$ git co trunk      # return to the local trunk
$ git svn rebase    # rebase the trunk from the Svn server
$ git br -d backup  # delete the backup branch

Ключ, конечно, заключался в том, что на этот раз работала перебаза. Я понятия не имею, почему это не сработало, когда я впервые это сделал, но я не могу отбросить часы, поэтому я не буду останавливаться на нем.

Еще раз спасибо за все предложения и терпение с новичком.

Ответ 3

Чтобы завершить sfossen отличный ответ, вот несколько деталей:

С git-svn по умолчанию вы получаете локальную ветвь с именем master. Вы не должны работать над этим, только обновляйте его с помощью ветки svn trunk с помощью:

git svn fetch, чтобы получить историю из ветки svn trunk в локальной ветке соединительной линии: он не будет применять эти изменения в вашем рабочем каталоге
git checkout master, чтобы включить ветвь соединительной линии (только если вы были на другой ветке)
git rebase trunk, чтобы синхронизировать мастер с trunk.

Однако все ваши изменения должны быть выполнены в другом локальном ветки (давайте назовем его local-devel).

git branch local-devel
git checkout local-devel

Если у вас есть срочное решение:

git checkout master: swith on master(),
git svn fetch && & git rebase trunk, чтобы обновить его с помощью svn trunk
git branch fastfix && git checkout fastfix, ответьте его
исправить ошибку, скомпилировать, протестировать,
git commit -a: локальная фиксация,
git svn dcommit обновить модификацию удаленного svn repo
git checkout master && git rebase trunk: обновить мастер снова
git branch -D fastfix: удалить ветвь исправления
git checkout local-devel && git rebase master: вернитесь к разработчику, с обновленной историей, сделанной мастером, воспроизведенным на ветке dev

Сначала это немного хлопот, но удобнее, чем svn diff в файле, который будет применяться позже.

Ответ 4

У меня была аналогичная ситуация. Я делал git svn dcommit по плохим сетевым соединениям, и в какой-то момент это не получилось. Я обнаружил, что проблема была вызвана тем фактом, что в репозитории Subversion уже был новый коммит, но локальный git -svn-аналог считал, что коммит еще не был в SVN. Решения других ответов здесь не помогли, однако это произошло:

git svn reset -r <last_svn_commit_git_was_aware_of>
git svn fetch
git svn rebase

После этого я, наконец, смог сделать git svn dcommit без ошибок.

Ответ 5

Я собирался прокомментировать, но думал, что это заслуживает большей видимости...

git svn rebase предполагается перезаписать ваши коммиты. Из описания и комментариев у меня создается впечатление, что после того, как вы переустановили, вы заставили свои старые коммиты вернуться наверх. Записи должны быть заменены более новыми версиями, которые не конфликтуют.

Чтобы избежать необходимости прорываться через reflog, вы можете захотеть получить быстрый тег перед тем, как сделать git svn dcommit. После успешного завершения dcommit удалите тег. Если тег терпит неудачу, вы можете сделать git reset --hard, за которым следует git merge <tag>. Повторно запустите свою rebase, чтобы вернуть историю в порядок, повторно пометить и повторно dcommit снова.

Ответ 6

Несколько мест, которые я прочитал, это плохая практика при использовании git svn для использования отдельной ветки. Что-то относящееся к git не появляется в svn так, как вы ожидали.

Следующий ответ http://progit.org/book/ch8-1.html представляется самым чистым способом:

git svn rebase
git svn dcommit

Я также попробовал самый популярный вариант выше, но он не всегда работал у меня, так как перезагрузка git не откатывается назад, чтобы соответствовать svn upstream, а просто назад к последнему git commit.