git svn rebase: неполные данные: источник Delta неожиданно закончился

Я поддерживал зеркало git проект watir. Некоторое время назад пару недель назад кто-то был готов представить свой первый патч на основе git. К сожалению, мы столкнулись с некоторыми проблемами, связанными с окончанием строк (CRLF против LF и т. д.) из-за многоплатформенного характера проекта.

Я попытался сделать все, что мог, чтобы установить опцию autocrlf (на 'input') и сделать кое-что - -жесткий сброс. Однако через несколько дней ежедневное обновление (git svn rebase) выдает эту ошибку:

Incomplete data: Delta source ended unexpectedly

Я пробовал искать в Google, что делать, но даже удаление параметра autocrlf в .git/config не помогло. Я боюсь, что рабочая копия повреждена, но я надеюсь, что это не является необратимым.

Очевидно, что возможный вариант действий — просто повторно импортировать из svn и запустить новое зеркало, но я надеюсь, что нам не придется этого делать, так как текущее watir-mirror уже разветвлено, и люди разработали новый код. в своих вилках.

Заранее благодарю за любую помощь.


git version-control svn corrupt
person Pistos    schedule 17.10.2008    source источник
comment
вы продвинулись дальше с этой проблемой? у нас сейчас такая же проблема. (и в прошлый раз проверка git-svn заняла 3 дня, поэтому я надеюсь, что смогу этого избежать)   -  person pvgoddijn    schedule 25.11.2009
comment
@pvgoddijn Нет, извините, разрешение так и не было найдено. Проблема просто ушла, потому что они официально перешли на github и отказались от svn.   -  person Pistos    schedule 30.11.2009

Ответы (5)


arrow_upward
17
arrow_downward

У меня была такая же проблема при попытке создать репозиторий git из репозитория brlcad svn. Я решил это, выполнив git svn reset --r XXXXX, где я установил XXXXX примерно на 50 ревизий до той, которая изначально вызвала ошибку.

Откат на одну ревизию не помог устранить ошибку. В рамках этого процесса я получил от git ошибки о том, что HEAD не определен. Чтобы решить эту проблему, я сделал git svn find-rev XXXXX, чтобы определить хэш, соответствующий нужной мне ревизии, а затем git checkout. После этого ошибки про HEAD пропали и git svn reset -r XXXXX заработало.

person Todd Wagner    schedule 08.02.2011
comment
Большое спасибо. Это помогает в аналогичной проблеме. Я просто установил номер версии на одну версию раньше текущей версии. - person Lei; 24.02.2011
comment
Это помогло, но сразу после того, как я убил все зомби-процессы git/perl и удалил файл index.lock. См. мой ответ здесь: stackoverflow.com/questions/21334923/ - person boskicthebrain; 14.07.2015

arrow_upward
5
arrow_downward

По личному опыту, git-svn всегда генерирует одни и те же коммиты при клонировании или извлечении из репозитория svn с одинаковыми параметрами (попробуйте: создайте фиктивный репозиторий, клонируйте его с помощью git-svn, сделайте еще несколько коммитов, снова клонируйте его, и получить первую копию; результирующие коммиты должны иметь точно такой же хэш).

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

person CesarB    schedule 17.10.2008
comment
Хеш остается прежним, да? Ну, я должен был знать/помнить, что git хеширует фактические байты дельты коммита. К сожалению, я могу столкнуться с разногласиями из-за того, что хочу решить проблему CRLF ‹-› LF во второй раз. Я попробую повторно импортировать, хотя. Спасибо! - person Pistos; 17.10.2008
comment
Хорошо, CesarB, я попытался повторно импортировать из источника svn, выполнив git svn init, установив autocrlf для ввода, затем git svn fetch - но я получаю ту же самую ошибку (дельта-источник...) в середине выборки . Любые другие предложения? - person Pistos; 18.10.2008
comment
Попробуйте вообще не играть с autocrlf, как с исходным зеркалом. Если эта ошибка будет продолжаться, я подозреваю, что это либо svn, либо git-svn. - person CesarB; 18.10.2008
comment
Что ж, без настроек crlf все работает нормально, но слияния паникуют из-за различий в конце строк и показывают огромные различия, хотя единственная дельта связана с пробелами. Я также пробовал пробел = cr-at-eol, но это, похоже, не помогает в этом отношении. - person Pistos; 24.10.2008
comment
В любом случае, это может быть заброшенная проблема, потому что проект watir, как сообщается, полностью переходит на git до конца года. Тем не менее спасибо за ваш вклад. - person Pistos; 24.10.2008

arrow_upward
4
arrow_downward

У меня была та же проблема с git svn fetch, но метод сброса мне не помог, возможно, потому, что я действительно не знаю, когда произошло повреждение. Вот что, наконец, сработало для меня. Я сделал git svn fetch --ignore-paths="/branches/", который прошел без ошибок. После этого я еще раз сделал свое git svn fetch, и на этот раз сработало.

person Don Branson    schedule 16.05.2013
comment
подход сброса тоже не сработал для меня. Но я не хочу игнорировать ветки. Что я должен делать? - person anony; 30.11.2013
comment
@anony вы просто игнорируете ветки в первой команде, затем, когда вы запускаете второй раз, вы не игнорируете ветки, и он выберет изменения. - person Don Branson; 30.11.2013
comment
Привет, Дон, у меня это не сработало. Я получаю следующую ошибку: Incomplete data: Delta source неожиданно завершился в /usr/lib/perl5/site_perl/Git/SVN/Ra.pm, строка 282. - person anony; 01.12.2013
comment
@anony - Хорошо, это просто означает, что часть, которую вы игнорируете (например, /ветки/), недостаточно широка. В вашем репозитории svn есть повреждение, но, по-видимому, не в /branchs. Возможно, вам придется полагаться на метод проб и ошибок, чтобы найти его. - person Don Branson; 02.12.2013

arrow_upward
0
arrow_downward

у меня была та же проблема, и, как и в случае с Тоддом, переход к предыдущей версии решил проблему.

Я думаю, что решение состоит в том, чтобы перейти к двум шагам предыдущей ревизии проблемного файла.

person yigit    schedule 10.02.2011
comment
как определить проблемный файл? - person anony; 01.12.2013

arrow_upward
0
arrow_downward

Я видел похожую проблему. Это происходит, когда я делаю частичный клон репозитория svn. Я предполагаю, что git-svn не может найти исходный источник файла при выполнении dcommit. Я исправил это, убедившись, что я полностью обновлен (git svn rebase), а затем использовал git svn set-tree для фиксации определенных изменений в subversion. Если у вас есть много изменений для фиксации, это может быть проблемой, поскольку вам нужно вручную фиксировать каждое изменение по порядку, но это работает хорошо, если у вас есть только одна или две фиксации для отправки.

person Trevor    schedule 28.08.2012