Git Svn dcommit error - перезапустить коммит

Question

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

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

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

Любые мысли приветствуются.

РЕДАКТИРОВАТЬ: Просто хотел указать, что я работаю локально. У меня есть локальная ветка для транка, которая ссылается на 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 ID.

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

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

Answer 1

Вы должны были создать локальную ветвь и выполнить эту работу, затем, когда вы вернетесь, вы обновите мастер, перебазируете в локальную ветвь, объединитесь с мастером, затем 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

Статья

Answer 2

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

$ 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

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

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

Answer 3

Для завершения sfossen отличный ответ , вот некоторые детали:

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

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

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

• git branch local-devel
• git checkout local-devel

Если вам нужно срочно исправить:

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

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

Answer 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 без ошибок.

Answer 5

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

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

git svn rebase
git svn dcommit

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

Answer 6

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

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

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