Безопасно ли прерывать вызов dcommit, который, кажется, зависает? - PullRequest
7 голосов
/ 15 ноября 2010

Я использую мост git-svn и переставил большое количество файлов в моем хранилище, поэтому он организован немного лучше.

Я запустил git svn dcommit, чтобы вернуть изменения на сервер SVN, и процесс, кажется, завис. Я не использую ЦП и не использую сеть для звонка dcommit за последние 45 минут. Выход застрял на:

> git svn dcommit
...snip...
     R       zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h
     R       zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h
     R       zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib
     R       zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb
     R       zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib
     R       zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb

И вот уже 45 минут.

Редактировать: в конечном итоге он закончился сообщением об истечении времени ожидания соединения HTTPS. Это заняло около полутора часов.

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

Я могу ответить на одну часть моего вопроса: что мне нужно сделать, прежде чем пытаться снова?

После истечения времени ожидания соединения и возвращения моего приглашения мне пришлось сделать git svn fetch, прежде чем я смог снова запустить git svn dcommit. Все мои операции переименования были найдены в репозитории SVN, но каталоги, которые были оставлены пустыми после перемешивания, не были удалены. Мне пришлось использовать мой SVN-клиент, чтобы удалить их. Я не уверен, что это вещь git-svn или из-за тайм-аута HTTPS во время этого вызова dcommit.

Я до сих пор не знаю ответа на вопрос: безопасно ли прерывание вызова dcommit?

1 Ответ

5 голосов
/ 16 ноября 2010

Да, это безопасно.

dcommit в основном делает это для каждого коммита , который вы отправляете в SVN:

  1. Вычислить разницу между коммитом и его родителем. (По сути, создание патча для коммита.)
  2. Отправьте это различие по протоколу SVN в качестве набора изменений для фиксации. После этого коммит теперь остается на сервере SVN.
  3. Извлечение нового коммита и любых других новых коммитов, которые были тем временем созданы другими пользователями, и локально сохраните их как надлежащие коммиты Git. Ссылка на ветку git-svn будет обновлена, чтобы указывать на последнюю версию.
  4. Перебазировать все коммиты после того, как только что обработанный, на ветку git-svn ref, на которую делается коммит. (Поскольку обрабатываемый коммит теперь должен находиться на сервере, это приведет к тому, что локальный коммит, который был только что обработан, будет отброшен, как при любом другом ребазе.)

Если вы прервете во время шага 2 (как это звучит), то текущий коммит будет прерван на сервере svn. Вы должны быть в состоянии снова принять участие без беспокойства.

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

...