Один из администраторов инфраструктуры проекта KDE описал (http://jefferai.org/2013/03/24/too-perfect-a-mirror/) подробности произошедшего несколько дней назад инцидента, которое разработчики KDE уже назвали "Великим бедствием KDE 2013 года". В результате случившегося, проект KDE чуть было не потерял содержимое всех Git-репозиториев, включая репозитории смежных проектов.
Всё началось с повреждения содержимого файловой системы Ext4 на первичном Git-сервере после неудачного перезапуска хоста. В результате сбоя файловой системы оказалась нарушена целостность Git-репозитория, содержимое которого было разрушено и данные многих репозиториев потеряны. Ситуация стала напоминать катастрофу, когда администраторы приступили к восстановлению данных из резервных копий. Дело в том, что для резервного копирования применялась практика зеркалирования Git-репозитория. Перебирая зеркала администраторов охватил ужас - система зеркалирования успела автоматически синхронизировать ошибочные данные на запасные репозитории, содержимое которых также пришло в негодность. Таким образом содержимое большинства репозиториев KDE было удалено.
История оказалась со счастливым концом - на одном из зеркал была найдена копия информации и содержимое репозиториев удалось полностью восстановить. Если бы не стечение обстоятельств, данная копия вполне могла бы не появиться. Дело в том, что за день до инцидента, в рамках переноса содержимого сервера на новое оборудование, была дополнительно настроена система клонирования репозитория на ещё не введённый в эксплуатацию новый сервер, при этом синхронизация была настроена на запуск раз в 20 минут и начало очередного цикла пришлось на перезагрузку проблемного сервера, что привело к завершению запуска скрипта полной синхронизации по таймауту и выполнению следом только скрипта загрузки последней ревизии из репозитория на сбойном сервере, который также завершился неудачей так как сервер не сумел сформировать корректный набор данныхВ итоге разработчики получили хороший урок и поспешили предупредить коллег об опасности излишнего доверия к расределённому характеру Git и использованию "git --mirror" в качестве способа резервного копирования.
URL: http://jefferai.org/2013/03/24/too-perfect-a-mirror/
Новость: http://www.opennet.me/opennews/art.shtml?num=36491
Ну и что? Даже если бы и потеряли, нашли бы какого-нибудь линуксоида с копией на домашнем компе.
Блин, точно! Надо будет себе ихний Git отзеркалировать.
Вдруг у них еще раз всё гребнется, и я окажусь единственным человеком на Земле с полной резервной копией сорцов KDE. Это же можно будет грохнуть Nepomuk и Akinadi, после чего вернуть код разрабам. А там пусть или зависимости удаляют, или заново всю эту дребедень пишут. Вот так вот.
Не поможет, т.к. вам надо будет периодически синхронизировать репозитории, а в результате такие же ошибочные изменения прийдут в ваш репозиторий.
Получится. Синхронизировать можно руками.
И что измениться? Разработчики KDE заметили повреждение не сразу - так, что оно уже успело разлиться на остальные сервера. Как правильно написали ниже: зеркалирование != бекапу.
Многие вытаскивают git'овые репозитории командой git fetch.В общем, какая-то пугалка из леса.
> такие же ошибочные изменения прийдут в ваш репозиторий.Так зачем синхронизироваться с использованием тупого мирроринга? При нормальном варианте синхронизации никто на ошибки не забивает. Это --mirror льет как можно быстрее, ничего не проверяя. Но это не штатный метод синка. И не метод бэкапа. Это лишь метод развернуть зеркало по быстрому. Из заведомо исправной копии.
> Вдруг у них еще раз всё гребнется, и я окажусь единственным человеком
> на Земле с полной резервной копией сорцов KDE.И вот тогда вы наконец сотрёте эту богомерзкую ДЕ!!! (шутка)
> будет грохнуть Nepomuk и Akinadi, после чего вернуть код разрабам.
> А там пусть или зависимости удаляют, или заново всю эту дребедень
> пишут. Вот так вот.Мне кажется тебе нужно оскар за идею дать !! :))
Хм, я уже около года сливаю с гитхаба серию интересных мне проектов, обычным git clone --recursive а потом git pull.
Сейчас разродился на скрипт пиотнячий, который тянет с гитхаба те проекты на которые я поставил Starred и заодно (пока неотключаемо) все репозитории владельца/организации. Т.к. обычно они пишут на близкие по духу проекты к отмеченному мной звездочкой.
Может паранойя, а вдруг завтра гитхаб как-то накроется, ну мало ли - метеорит упадет или повстанцы захватят офис и фирма владелец навернется из-за кризиса. А так в дождливые вечера будет что поковырять.
гугль ещё скачай, чтобы почитать что было.
все 1500 гигабайт
Хорошо если бы потеряли. У программеров на компах все равно все есть, а всякие ненужные хрени канули бы в лету.
> Хорошо если бы потеряли. У программеров на компах все равно все есть,
> а всякие ненужные хрени канули бы в лету.По крайне мере это показало бы какие долбоносы принимают ключевые решения в важнейших частях линукса.
Теперь жду когда что-то грохнется у ядерщиков по вине systemd.
Ничего. Репликация не средство бэкапов. Вот и весь урок. Обычных бэкапов это НЕ ОТМЕНЯЕТ. Кушайте с булочкой, о великие линуксойды!
в неумелых руках и git - ftp
это цитата дня!!!
А им не приходило в голову исключать сервер из списка для зеркалирования до момента зевершения тех.работ на этом сервере?:) Или я чего-то в git-е недопонял?
> А им не приходило в голову исключать сервер из списка для зеркалирования
> до момента зевершения тех.работ на этом сервере?:) Или я чего-то в
> git-е недопонял?статья намекает что зеркалирование у них было сделану через жопу. тоесть не через гит-чекауты(что не позволило бы пройти чекауту с битыми файлами на сервере.) ну и да корневой сервер в гит? поржалъ спасибо.
> статья намекает что зеркалирование у них было сделану через жопу.ну так кде, у них теперь всё так.
> А им не приходило в голову исключать сервер из списка для зеркалирования
> до момента зевершения тех.работ на этом сервере?:) Или я чего-то в
> git-е недопонял?всё бы ничего но у них ЕЯП из предположения что мы абсолютно доверяем всему что происходит на корневом сервере синкался в том числе конфиг того скрипта который им всё мирорил со списком репозиториев которые должны жить чтобы при удалении репозитория с основного сервера он автоматом удалялся с остальных... вот эта часть им больше всего проблем принесла ЕЯП
фейл при 1500 бекапах - было бы эпично
Ибо это были не совсем бакапы, точнее совсем не бакапы.
> Ибо это были не совсем бакапы, точнее совсем не бакапы.И вот так в гите очень многое сделано. Вроде и команда делает Y, но если подумать, то не совсем Y, а как попробуешь в действии -- так и вовсе Z. + репа живёт своей жизнью (я про периодический gc).
> репа живёт своей жизнью (я про периодический gc).отключи, в чём проблема?
> жизнью (я про периодический gc).Так он настраивается на все вкусы. Програмер - это ж все-таки не обезьяна класса "оператор ПК", который тупо колотит в базу.
>> жизнью (я про периодический gc).
> Так он настраивается на все вкусы. Програмер - это ж все-таки не
> обезьяна класса "оператор ПК", который тупо колотит в базу.Чем больше работаю в ИТ, тем всё больше в этом сомневаюсь...
Повезло...
А как же аксиома "Зеркалирование != резервное копирование"?
Вот вот. И как минимум 2-а прошлых бекапа должны быть.
А то и десяток.
Ежедневные за неделю еженедельный за квартал, ежемесячные за пару-тройку лет. Далее - ежеквартальные. Тогда голова обычно не болит. Можно и побольше.
Если слишком тяжеловесно и дорого хранить - осетр вдумчиво урезается или оптимизируется.
> А как же аксиома "Зеркалирование != резервное копирование"?оригинал статьи с этих слов и начинается...
Зачем такой бэкап нужен?
> Зачем такой бэкап нужен?Зачем он вообще нужен? Анон сбережет!
А им не приходило в голову, что делать из распределенной системы централизованную систему с "первичным" сервером - это фейл по надежности?
> А им не приходило в голову, что делать из распределенной системы централизованную
> систему с "первичным" сервером - это фейл по надежности?Им не приходило в голову и что зеркало != бэкап. В общем, незачетно облажались, увы и ах.
БЭКАПЫ??? почему не используют бэкапы? хотя бы раз в неделю можно делать такоеили как минимум - снапшоты
А зачем делать бэкапы, если у каждого разработчика есть локальная копия репозитория Git? Для восстановления главного репозитория достаточно хотя бы одного уцелевшего локального. Или разработчики хранили все свои локальные репозитории Git на одном сервере (что косвенно подтверждается из статьи)? Ну так сами себе и идиоты.
Вот затем и. Мы, например, делаем (и порой проверяем).
Какой толк от локальных копий, когда они уже синкнулись с битым репозиторием?
>Какой толк от локальных копий, когда они уже синкнулись с битым репозиторием?А что, git разучился проверять репозиторий на целостность? Нет пути!
Пардон, если кто с --mirror синканулся - кто же ему доктор?
> А зачем делать бэкапы, если у каждого разработчика есть локальная копия репозитория Git?Потому что бегать по разработчикам и выцарапывать свои репы - не очень быстро и удобно, знаешь ли. И предполагает некую степень доверия, etc.
> быстро и удобно, знаешь ли. И предполагает некую степень доверия, etc.Тэги подписаны gpg.
> Тэги подписаны gpg.Если подписаны. И да, это означает продолб работы с момента расстановки тега...
> БЭКАПЫ??? почему не используют бэкапы? хотя бы раз в неделю можно делать
> такое
> или как минимум - снапшотыу них на самом деле есть и нормальные бэкапы, но они их делают реже.
snapshot != backup
> или как минимум - снапшотыТебе будет очень приятно узнать что при дестрое ФС осыпается не только блок, но и все что от него зависело. И в общем случае снапшотная механика при разрушениях может очень серьезно встать раком.
Сисадмины делятся на три группы:
1. Которые скоро начнут делать бекапы
2. Которые уже делают бекапы
3. Которые уже проверяют, чтобы разбекапливалосьПо теме: нахер вообще зеркалить гит? Зеркалить надо историю изменений, без возможности затирания или перезаписи старых изменений на любом зекале. Ну и нормальные бекапы тоже ни кто не отменял, пара терабайт не такие уж и большие объёмы для проекта уровня кде, можно и пару насов под это дело дать, чтобы ежедневки хотя бы неделю хранить. А лучше немного потратиться и ежечаски хранить неделю.
> Сисадмины делятся на три группы:
> 1. Которые скоро начнут делать бекапы
> 2. Которые уже делают бекапы
> 3. Которые уже проверяют, чтобы разбекапливалось
> По теме: нахер вообще зеркалить гит?Для снятия нагрузки с основного сервера. Сотни разработчиков (ну хорошо, активных - несколько десятков) + куча билд-серверов, один сервак всё это не вытянет никак.
>> По теме: нахер вообще зеркалить гит?
> Для снятия нагрузки с основного сервера. Сотни разработчиков (ну хорошо, активных -
> несколько десятков) + куча билд-серверов, один сервак всё это не вытянет
> никак.Сотни, десятки, кучи.
Да как два байта переслать вытянет, не девятнадцатый же век на дворе.
И больше вытягивают.И кластеры ни кто не отменял, кстати.
>>> По теме: нахер вообще зеркалить гит?
>> Для снятия нагрузки с основного сервера. Сотни разработчиков (ну хорошо, активных -
>> несколько десятков) + куча билд-серверов, один сервак всё это не вытянет
>> никак.
> Сотни, десятки, кучи.
> Да как два байта переслать вытянет, не девятнадцатый же век на дворе.
> И больше вытягивают.Вы забыли про SSH и специфичную для собственно Git математику (та самая проверка хешей и т.д.) при подключении. Это вебдванадесять-сайты раздавать просто.
> И кластеры ни кто не отменял, кстати.
Дык у них и был, и есть кластер. С одним ведущим сервером. Буквосочетание master-slave знакомо?
Жесть, они не бекапируют свои сервера? Как уже сказал человек выше "зеркалирование != резервное копирование".Ужасно..
Двойной хэдшот: Ext4 и Git оказались повреждены.
> Двойной хэдшот: Ext4 и Git оказались повреждены.Сдуру можно и ... сломать. То что это виртуалка - вызывает подозрения что оно вообще на семантику синхронизации с диском могло класть ради скорости, например. А то некоторые наимные чукотские юноши думают что виртуализатор работает быстрее голой железки за счет каких-то чудодейственных свойств. А потом и оказывается что чудеса были за счет забивания на синхронизацию буфферов на диск... :)
Сказал любитель BSD и Mercurial-а :)
Ну, по части любви к Mercurial я с тобой солидарен.
Про Ext4 ничего не скажу.
> Сказал любитель BSD и Mercurial-а :)и ZFS.
просто мёд! дабл фэйл! нужно утащить этот линк и в следующий раз пугать им крикунов типа ext4 меганадежен, git не ломаем, там жэ хэши!...
виртуалка тоже небось под каким-нить XEN/KVM крутилась, и это тоже доставляет!
Ишь, стервятников с гетзефаксами поналетело. Вот мы и видим кто друг а кто сундук.
Причём тут надёжность EXT4? Кто сказал что железо было в порядке? Знаете хоть одну файловую систему которая гарантировано не потеряет консистентность на железе с битой памятью? И вообще подробностей про EXT4 нет - может файловая система в порядке, а файлы нет (такое тоже ни одна ФС не гарантирует)
А кто сказал что железо было не в порядке? Никто. А сказали: повреждение Ext4...
> повреждение Ext4...Сферическое повреждение в вакууме - не аргумент. В мире есть миллионы методов повредить ФС, при том в половине случаев ФС будет вообще не виновата. Если это какой-то баг в EXT4 - одно дело. А если это продолб в конфигурации виртуалки, баг виртуализатора или еще какая-то хрень - так это вообще к другим докторам.
> просто мёд! дабл фэйл! нужно утащить этот линк и в следующий раз
> пугать им крикунов типа ext4 меганадежен, git не ломаем, там жэ хэши!...О, а забрасывайте и мне ссылки на ссылку -- буду архивировать и показывать детишкам, что бывает из неграмотных бздюков, которые не понимают того, что когда-нибудь разваливается _всё_ -- и ext4, и меркава.
Вы хоть избыточность хранилища данных с бэкапом не считаете взаимозаменяемыми, надеюсь?
>> просто мёд! дабл фэйл! нужно утащить этот линк и в следующий раз
>> пугать им крикунов типа ext4 меганадежен, git не ломаем, там жэ хэши!...
> О, а забрасывайте и мне ссылки на ссылку -- буду архивировать и
> показывать детишкам, что бывает из неграмотных бздюков, которые не понимают того,
> что когда-нибудь разваливается _всё_ -- и ext4, и меркава.У нас тут Т34 стоит и не разваливается ...
> У нас тут Т34 стоит и не разваливается ...Это вы на UFS так намекаете? :)
>> У нас тут Т34 стоит и не разваливается ...
> Это вы на UFS так намекаете? :)Нет на памятник.
В многоэтажке живете?Кстати, а где Arisu и прочие клованы, что бесновались в каждой новости о FreeBSD с SVN?
ждут Патчей, видимо. или даже Попатченные_версии_в_няшном_репозитории
> В многоэтажке живете?
> Кстати, а где Arisu и прочие клованы, что бесновались в каждой новости
> о FreeBSD с SVN?arisu и прочим клоунам ссылку на новость надо будет теперь давать всегда, если начнут сотрясать воздух. Как пример того, что даже при в целом надёжных и распределённых инструментах можно облажаться, если руки из жопы.
> даже при в целом надёжных и распределённых инструментах можно облажаться,
> если руки из жопы.Ну Вы-то ведь понимаете, что главная проблема была в неприменении обычного бэкапа при том, что релевантные в этом плане свойства используемой DSCM были помножены на ноль конкретикой применения?
Это даже не руки, скорее безмятежное отсутствие набитых шишек было.
Потеряв свой первый архив почты где-то в 2000 или 2001, второй бэкаплю :)
PS: тем, кто начинает тут сопли про SVN разводить: ну головой-то хоть подумайте, "неклоуны", где проблема, а где та разница, которую пытаетесь за уши притянуть.
> Ну Вы-то ведь понимаете, что главная проблема была в неприменении обычного бэкапа
> при том, что релевантные в этом плане свойства используемой DSCM были
> помножены на ноль конкретикой применения?
> Это даже не руки, скорее безмятежное отсутствие набитых шишек было.Да, конечно. Это ещё раз говорит о том, что надо внимательно читать описание инструментов, прежде чем ими пользоваться. И, как тут уже заметили, у них и не было бекапа, по сути... К гиту претензий тут нет...
> целом надёжных и распределённых инструментах можно облажаться, если руки из жoпы.А что, это для вас открытие? Вроде бы законы Мерфи написали далеко не вчера...
То что разваливается всё, это и так понятно. Но то что у Грамотных Линуксоидов _после_обновления_, _и_перезагрузки_ раскромсало _надёжную_etx4_ это что-то... Они что, не в курсе, что линукс сейчас это не тот линукс, который был 5-6 лет назад? Или на всё возрастающую глюкодромность как-то принято закрывать глаза, лишь бы корпорасты платили? Да и вообще, перед обновлением и ребутом всегда неплохо бы постелить соломки... Чтобы "по Git-у текло, а в бекап не попало".
> возрастающую глюкодромность как-то принято закрывать глаза,Так функционал возрос. Они вон на виртуалочке, с зеркалами, все дела. Вы сами такое поднимите не на линуксе, а мы и сравним у кого глюков будет больше. А то некоторые которые тут гарцуют - вообще повылетели нафиг из всей энтерпрайзятины за вообще полное и хроническое неумение этой самой виртуализации.
Ещеб чуть чуть и EXT4 вошла бы в историю :)))
так это плазма упала на севере (
(шутка)
> так это плазма упала на севере (
> (шутка)Набрала критическую массу и вырвалась из электромагнитной ловушки, генерируемой железом сервера :)
Ага! Хотели хорошее KDE3 якобы "потерять", но сисадмины так невовремя склонировали репозиторий?
А при чем здесь KDE3?
Да, кстати, как пропатчить КДЕ?
Спросите у анимешников
Мне не понравилось четвёртое и я пользуюсь третьим. Таких как я много: существуют сборки для последних версий всех популярных дистрибутивов Linux. Добавлена поддержка Udisks, Udisks2 и обеспечена сборка в GCC 4.7. Вот и хотят пресечь возможность установки KDE версии меньше 4. Знаю что это вряд ли, но вдруг?!
Я думаю, что тебе следует помалкивать о своей любви к 3-й версии, а то не ровен час и к тебе придет кровавая гэбня. Тогда тебе точно не сдобровать, они будут пытать и таки заставят тебя использовать 4-ю версию!
> хотят пресечь возможность установки KDE версии меньше 4.А надзирателей для контроля за ходом пресечения пришлют?
Представь себе что ты - Сергей Лукьяненко, и ты издаёшь книги "Последний дозор" и "Новый дозор". А их никто не читает, все читают только Ночной и Дневной, в редких случаях Сумеречный дозор. Обидно? Обидно. Вот я об этом говорю. Только Лукьяненко не может взять и отправить надзирателей, чтобы они отобрали у читателей старые книги и заставили купить новые, а разработчики KDE могут стереть старые и по-прежнему популярные версии KDE с сервера.
> а разработчики KDE могут стереть старые и по-прежнему популярные версии KDE с сервера.Останется сущая мелочь - убедить всю ораву склонировавшую репу проделать то же самое. Иначе оно так и будет циркулировать там и тут. Если это получится - значит над проектом никто более работать не хочет. Вобще никак. Ну а дохлые проекты - не жалко.
> а разработчики KDE могут стереть старые и по-прежнему популярные
> версии KDE с сервера.всем по барабану. во-первых, есть TDE, во-вторых, то, что однажды попало в интернеты, больше не пропадёт.
> Мне не понравилось четвёртое и я пользуюсь третьим. Таких как я много:
> существуют сборки для последних версий всех популярных дистрибутивов Linux. Добавлена
> поддержка Udisks, Udisks2 и обеспечена сборка в GCC 4.7. Вот и
> хотят пресечь возможность установки KDE версии меньше 4. Знаю что это
> вряд ли, но вдруг?!зеня ты был хорошим человеком, но есть вещи про которые нельзя даже думать, а уж темболее намекать!
А так написали бы следующую версию KDE с нуля. Может лучше бы получилось ;)
Разработчики должны были усвоить всего один урок - админ отождествляющий понятия mirror и backup должен быть с позором изгнан из профессии. Ну а выставлять git причиной отсутствия бэкапа - расписаться в полной некомпетентности.
Где-то верно. Я ниже сделал предположение, что там кто-то оказался админом по совместительству.
> Разработчики должны были усвоить всего один урок - админ отождествляющий понятия mirror
> и backup должен быть с позором изгнан из профессии. Ну а
> выставлять git причиной отсутствия бэкапа - расписаться в полной некомпетентности.Вы скольких, новых, высококвалифицированных администраторов уже подготовили?
Плюс, за одного битого двух небитых дают!
Плазма чудом не упала.
Жаль. А то получился бы эталонный фейл.
Преувеличено слегка, наверняка у кого-нибудь из зеркальщиков были бы снапшоты вчерашние.
Если ваша файл хранится менее, чем в трех независимых местах, можете считать, что его не существует.
Настройкой и поддержанием всяческих репов и зеркал занимаются админы, и это их работа.
Разработкой занимаются разработчики.
В софтверных группах и фирмах случается когда кто-то из разработчиков по совместительству чего-то админит. Ибо там каждый сам сусам и головаст.
И иногда срабатывает не в лучшую сторону отличие в психологии и манере работы.
По тому как эмоционально описывает инцидент "один из администраторов", он более похож на "совместителя".
Классический админ не гнал бы такую волну эмоций, а с отвращением почесывал бы затылок и прикидивал бы как оптимизировать минимальное число телодвижений с минимально-необходимым отбрехиванием и на чем остановиться - на заначенном полном архиве репов недельной давности или стыковать солянку из более свежих но разрозненых копий репов. И еще прикидывал бы с кого бы под шумок срубить пару бутылочек виски и всяких полезных для хозяйства хомячков.
Образ у вас получился какой-то... не очень приятный, я бы сказал. Вместо "любой ценой поднять всё" как хотел бы любой, кто болеет за судьбу своего проекта - искать, с кого бы слупить вискарь.
Нормальный образ.Админ - он по природе своей родственен завхозу или хомяку. У него всегда должна крутиться мысль о том, что с кого можно слупить. А кроме того он прежде чем что-то делать хорошенько думает о всяком разном (если нормальный админ).
И Вы заблуждаетесь, полагая, что размышления о том чего бы можно было перехватить помешают нормальному админу добросовестно провести восстановление порушенного. А вискарь он срубит в качестве моральной компенсации, причем не с того, кому нужна рабочая система, а с того, кто оказался как-то повинен в ее обрушении либо препятствовал повышению ее надежности. И разопьет этот вискарь скорее всего с теми, кто чем-то в хозяйстве поможет.
А дергаются и бьют в грудь о том, как они стремятся любой ценой поболеть за судьбу проекта - это скорее разработчики. Они люди горячие, думают быстро, быстро делают, быстро отправляют на тестирование или эксплуатацию... Потому как у них проект... Вот в таком вот стиле похоже и появилось зеркалирование без бэкапирования.
А у админа не проект, у него - хозяйство. :-)
Как хорошо, что такие моральные уроды это исключение в нашей профессии, а не правило.
> Как хорошо, что такие моральные уроды это исключение в нашей профессии, а
> не правило.Опиши не урода, плиз
это Вы себя описываете?! мелко... ))
2 статьи про недочеты git за день, это знак. надо посмотреть что там сейчас у меркуриала
> недочеты git [...] надо посмотреть что там сейчас у меркуриалаТак точно то же, если "бэкапить" rsync без снапшотов. Если Вы пытались что-то умное сказать, то всё-таки постарайтесь сперва разобрать ситуацию, в которую вляпались kde-шники, на составные части -- и подумайте о том, какие свойства каких частей надо менять, чтобы хоть именно в такую не вляпаться.
Он не должен был отдавать поврежденные данные во-первых. У вас что-то личное с git, что вы его так защищаете не смотря ни на что?
> У вас что-то личное с git, что вы его...пытаетесь обляпать, несмотря ни на что?
Возьмите листик бумаги, нарисуйте на нём всю упаковку байтиков от "вижу коммит" до "лежит на диске", внимательно перечитайте уже отписавшихся в треде грамотных людей и подумайте ещё раз.
Пока у Вас, к сожалению, не получилось -- но надеюсь, с карандашом в руке дело пойдёт. (это не наезд ни разу, сам так с ручника порой снимаюсь -- может, и у Вас эта инженерная болячка есть)
Я к тому, что проверки не должны неявно опускаться при "каком-то --mirror", они должны явно опускаться при каком-нибудь "--skip-checks". Даже в мане ничего об этом не сказано, я проверил. Хрестоматийное нарушение принципа POLA, которой, кстати, бздуны стараются чтить.
> Я к тому, что проверки не должны неявно опускаться при "каком-то --mirror",
> они должны явно опускаться при каком-нибудь "--skip-checks". Даже в мане ничего
> об этом не сказано, я проверил. Хрестоматийное нарушение принципа POLA, которой,
> кстати, бздуны стараются чтить.mirror - это "идентично". Зеркало не должно кривую рожу распрямлять.
> mirror - это "идентично". Зеркало не должно кривую рожу распрямлять.умри, Денис, лучше не скажешь! ~(ц)
> Он не должен был отдавать поврежденные данные во-первых.Mirror - для ускоренного разворота зеркал. Быстрого. С исправной копии. А то что дай дураку стеклянный шар, он и шар разобьет и руки порежет - ну, бывает...
>это знак. надо посмотреть что там сейчас у меркуриалаТам отсутствие статей. То есть фейл только один. Но изо дня в день.
Нет, описываю не себя. Я как-то больше в последнее время все больше с людьми работаю. Вот и описываю впечатления о тех, кто где хорош на мой взгляд.
У кодеров, познания могут быть ширше и глубже. Ну и стоят они при этом...
Но в последнее время кодеры попортились. Они в своем менталитете слишком часто завязаны на почасовку в работе. А что еще хуже, все более тяготеют сбрасывать на тестирование или эксплуатацию код, который сами ни разу не посмотрели в работе.
Админы ориентируются не на почасовку, а на профилактику в целях обеспечения круглосуточного функционирования систем. И потому хороший админ избегает аварийных ситуаций, хомячит дополнительные резервные ресурсы и старается делать минимальное количество значимых телодвижений. Но то что делает тщательно проверено им лично.
Правильно говорят, сложная штука этот git. А что, нельзя было сделать git clone и синхронизировать с upstream вместо такого зераклирования (не силён в git, сильно не бейте)?
> Правильно говорят, сложная штука этот git. А что, нельзя было сделать git
> clone и синхронизировать с upstream вместо такого зераклирования (не силён в
> git, сильно не бейте)?Вот они так и сделали.
>> Правильно говорят, сложная штука этот git. А что, нельзя было сделать git
>> clone и синхронизировать с upstream вместо такого зераклирования (не силён в
>> git, сильно не бейте)?
> Вот они так и сделали.Нет, простите. git clone проверяет целостность, с убитого в хлам репа он обновлять не будет.
> Вот они так и сделали.Нет, они не так сделали. Они git --mirror поюзали, а это быстрый разворот зеркала из исправной копии. При этом как раз проверок не делается чтобы быстрее работало.
Но юзать такие технологии не для создания начальной копии-зеркала а для бэкапа? Ать-ать-ать, за такую квалификацию руки надо отрывать.
> Но юзать такие технологии не для создания начальной копии-зеркала а для бэкапа?
> Ать-ать-ать, за такую квалификацию руки надо отрывать.дык а в ext4 сделали наконец снепшоты или "устаревшая ufs2" и тут жжот, по сравнению с?
> дык а в ext4 сделали наконец снепшотыИх сделали, как известно, в lvm. Мало того, снапшот тут был бы полезен разве что для сливания с него в сторонку бэкапа и прибивания. Конкретно в случае git можно и без снапшота на уровне ФС/БД организовать заведомо непротиворечивую копию.
Ох уж мне эти шпециалисты по страшным словам...
>> дык а в ext4 сделали наконец снепшоты
> Их сделали, как известно, в lvm. Мало того, снапшот тут был
> бы полезен разве что для сливания с него в сторонку бэкапа
> и прибивания. Конкретно в случае git можно и без снапшота
> на уровне ФС/БД организовать заведомо непротиворечивую копию.только вот с "древней" fs в этот момент работать можно.
> Ох уж мне эти шпециалисты по страшным словам...Сильную обиду чувствую я!:)
>> Конкретно в случае git можно и без снапшота на уровне ФС/БД
>> организовать заведомо непротиворечивую копию.
> только вот с "древней" fs в этот момент работать можно.Эва, на бронепоезде -- читать умеем или сразу рефлекторно пишем?
>>> Конкретно в случае git можно и без снапшота на уровне ФС/БД
>>> организовать заведомо непротиворечивую копию.
>> только вот с "древней" fs в этот момент работать можно.
> Эва, на бронепоезде -- читать умеем или сразу рефлекторно пишем?т.е. след. коммент ты потер, а свой, блестящий, оставил? давай переквочу, специально для тех кто слаб глазами/не может держать в уме больше 1 прочтенной строки:
>> дык а в ext4 сделали наконец снепшоты
> Их сделали, как известно, в lvm. Мало того, снапшот тут был <фапанье на git выброшено>теперь стало ясно, к чему было сообщение, в ответ на которое ты поведал что ездишь в бронепоезде?
> т.е. след. коммент ты потерТак он выставлял Вас как полного дурака, обида разве что в том и может состоять. Но если хотите -- специально попрошу Максима, чтоб восстановил написанный Вами и удалённый мной #228. И пусть дурь будет привселюдна.
> давай переквочу, специально для тех кто слаб глазами/не может держать
> в уме больше 1 прочтенной строки:
>>> дык а в ext4 сделали наконец снепшоты
>> Их сделали, как известно, в lvm.
> теперь стало ясно, к чему было сообщение, в ответ на которое ты
> поведал что ездишь в бронепоезде?И ведь вроде же Вы не так давно ещё проявляли признаки наличия интеллекта...
ДА НЕ НУЖНЫ ТУТ СНАПШОТЫ, БЛОНДИНКА. НЕ ПОМОГУТ. НИ ТЕ, НИ ЭТИ, НИ ТРЕТЬИ.
По самой что ни на есть тривиальной причине: ФАЙЛОВАЯ СИСТЕМА И БЛОЧНОЕ УСТРОЙСТВО В ПРИНЦИПЕ НЕ МОГУТ ОБЕСПЕЧИВАТЬ ЦЕЛОСТНОСТЬ ОПРЕДЕЛЯЕМЫХ СЛОЕМ ВЫШЕ СТРУКТУР ДАННЫХ.
Для клинически непроходимых головой "мегоодминов", которые вообще не понимают, как работают компьютеры -- могу и на пальцах: если git в момент формирования снапшота на уровне ФС как раз изменял данные (либо ФС в момент формирования снапшота на уровне block device) -- то снапшот может оказаться попросту неконсистентным.
Для формирования заведомо пригодного к созданию _надёжной_ резервной копии снапшота требуется уметь структуры данных и блокировки на уровне приложения, которое пишет. Будь это SCM или РСУБД.
Будете ещё так выступать -- я ведь не поленюсь и соберу консилиум грамотных BSD-шников, чтоб Вам мозги вправили и рот открывать стало хоть на некоторое время стыдно о том, в чём понимаете даже меньше меня.
Доступно сказано?
>> т.е. след. коммент ты потер
> Так он выставлял Вас как полного дурака, обида разве что в том
> и может состоять. Но если хотите -- специально попрошу Максима,
> чтоб восстановил написанный Вами и удалённый мной #228. И пусть
> дурь будет привселюдна.ты правда не понимаешь о чем речь выше по треду или прикидываешься? Еще раз повторю, в надежде что с N-го раза поймешь. речь шла о есть/нет снепшоты на уровне fs, в ключе "древней и тормозной ufs2" vs модной/молодежной/стабильной/etc ext4 (смотри новость о FreeNAS). сколько раз нужно повторить чтобы дошло?
> И ведь вроде же Вы не так давно ещё проявляли признаки наличия
> интеллекта...извини, всеже не буду "Вы"кать, раз беседа "задалась". так вот, ты тоже проявляешь данные признаки, временами. что сейчас мешает?
[тут мой браузер отказался квотить истерику]
> Для формирования заведомо пригодного к созданию _надёжной_ резервной копии снапшота требуется
> уметь структуры данных и блокировки на уровне приложения, которое пишет.
> Будь это SCM или РСУБД.гениально! только где я писал обратное?
> Будете ещё так выступать -- я ведь не поленюсь и соберу консилиум
> грамотных BSD-шников, чтоб Вам мозги вправили и рот открывать стало хоть
> на некоторое время стыдно о том, в чём понимаете даже меньше
> меня.пока будешь собирать, тебя, надеюсь, отпустит, так что давай, собери.
> Доступно сказано?
> дык а в ext4 сделали наконец снепшоты или "устаревшая ufs2" и тут жжот, по сравнению с?Я конечно понимаю что трындеть языком без понимания процессов - это просто. Но это вы просто не видели как снапшотная механика заваливается в случае каких либо неидеальностей на диске. Бывает у кулсисопов.
git как всегда фейл, сколько бы не кричали git-фанбои
Git не фейл, это просто _не_ система бэкапирования.
>Git не фейл, это просто _не_ система бэкапирования.Ага, бэкапить все 1500 серверов? Да я тебя!
так ведь речь идет о функции бекапа, не?
В данном случае таки фейл.
Ибо трабла в том что git mirror не делает проверку целостности.
Это изначально фейл. Такого быть не должно.
> Ибо трабла в том что git mirror не делает проверку целостности.Ещё раз: "неча на зеркало пенять, коли рожа крива". Это не только про git, кстати.
Еще раз : Если git mirror не делает проверку целостности, это таки фейл гита.
Скопировать директорию гита без контроля целостности любым сподручным инструментом.И да, это конечно же не означает, что все остальное белое и пушистое.
> git mirror*sigh*
Нету такого. Есть git clone. Который в т.ч. умеет:
--mirror
Set up a mirror of the source repository. This implies --bare.
Compared to --bare, --mirror not only maps local branches of the
source to local branches of the target, it maps all refs (including
remote-tracking branches, notes etc.) and sets up a refspec
configuration such that all these refs are overwritten by a git
remote update in the target repository.
>[оверквотинг удален]
> Compared
> to --bare, --mirror not only maps local branches of the
> source
> to local branches of the target, it maps all refs (including
> remote-tracking
> branches, notes etc.) and sets up a refspec
> configuration
> such that all these refs are overwritten by a git
> remote
> update in the target repository.
Миш, ну вот откуда я из этого описания должен догадаться об отключённых проверках целостности?
> Миш, ну вот откуда я из этого описания должен догадаться об отключённых
> проверках целостности?Я насторожился на слове "overwritten", хотя с тем, что стоит написать более красной краской -- согласен, конечно.
Возможно, из этой новости получится хорошая секция TRIVIA...
> Миш, ну вот откуда я из этого описания должен догадаться об отключённых проверках целостности?Окей, написано не идеально. Но зачем вообще вкорячивать программам опции, смысл которых не до конца понятен вкорячивающему?
>> Миш, ну вот откуда я из этого описания должен догадаться об отключённых проверках целостности?
> Окей, написано не идеально. Но зачем вообще вкорячивать программам опции, смысл которых
> не до конца понятен вкорячивающему?Что конкретно Вам непонятно в описании этой опции?
> git как всегда фейлПри чём тут git? Так можно и на rsync кивать вместо головы и рук.
>> git как всегда фейл
> При чём тут git? Так можно и на rsync кивать вместо
> головы и рук.А при том, что не умеет толком проверять репозиторий на наличие фатальных повреждений.
Умеет, но KDE-шники нашли такую опцию, чтобы это отключить
> А при том, что не умеет толком проверять репозиторий на наличие фатальных повреждений.В данном случае дураки в очередной раз обдурили защиту от себе подобных, явным образом вырубив это :)
Найдите, где об этом в описани опции написано, явный вы наш.
>> git как всегда фейл
> При чём тут git? Так можно и на rsync кивать вместо
> головы и рук.При том что rsync сторонняя прога, которая ничего о структуре и целостности копируемых данных сверх предоставляемых FS не должна. ПО ОПРЕДЕЛЕНИЮ.
А вот git - ОБЯЗАН обеспечивать целостность на уровне git.
Это аксиома.
> А вот git - ОБЯЗАН обеспечивать целостность на уровне git. Это аксиома.1) у виндузятников на всё своя аксиоматика, но это их проблема;
2) #63
> А вот git - ОБЯЗАН обеспечивать целостность на уровне git.Если уж человеки в 1986 умудрились взорвать ядерный реактор, хотя там навороченная многоуровневая система защит - что уж тут удивляться какому-то вшивому гиту в каком-то кде?
>> А вот git - ОБЯЗАН
> Если уж человеки в 1986Ммм, ну, там эксплуатационщикам тоже, как выяснено на OpenNET, не всё написали в man-е. Однако в части последствий ваша аналогия, "немного не того".
> умудрились
> Если уж человеки в 1986 умудрились взорвать ядерный реактор,
> хотя там навороченная многоуровневая система защитСпасибо доброму человеку, который меня тут как-то ткнул носом в записки Дятлова при виде подобной глупости про "человеческий фактор"...
Обязательно (да, я требую этого) прочтите эту краткую выдержку:
---
Первой появилась работа профессора Б. Г. Дубовского "О факторах
неустойчивости ядерных реакторов на примере реактора РБМК". Б Г. Дубовский в
1958-1973 гг. был начальником службы ядерной безопасности в СССР и реактор
РБМК знает не по наслышке. Еще в 70-х годах давал предложения по улучшению
защиты именно этих реакторов.
В работе подробно рассмотрены и объяснены пороки СУЗ реактора. Вот они.
Активная зона имеет высоту семь метров, поэтому возможно возникновение почти
самостоятельных реакторов внизу и вверху зоны. В то же время все стержни
СУЗ, задействованные в A3, расположены вверху, и при возникновении
локального реактора внизу поглотители нейтронов туда вводятся с большим
опозданием. В СУЗ РБМК были еще так называемые укороченные
стержни-поглотители. Они всегда расположены в нижней части активной зоны или
выведены из нее вниз. Поэтому они могут низа зоны достичь быстро. Но
<из-за допущенного грубейшего, совершенно нелогичного просчета в проекте
защиты стержни УСП не были подключены к сигналу общей аварийной защиты АЗ-5,
что исключило их быстрое введение в объем возникновения неконтролируемого
зонального реактора в нижней части активной зоны - в самый опасный район с
точки зрения разгона реактора>.
Внизу активной зоны локальный реактор создавался не по технологическим
причинам, он создавался самой системой СУЗ. Из-за неоднородности стержней
(поглотители, вытеснители, столбы воды) при нахождении стержня вверху в
нижней части канала - столб воды высотой 1,25 м. Замещение этих столбов
графитовым вытеснителем, слабее поглощающим нейтроны, и создает местный
реактор.
<Наличие столбов воды под графитовыми вытеснителями обусловило
второй грубейший просчет в конструкции системы СУЗ>. Комментарии Б.Г.
Дубовского к этому явлению: <К великому сожалению, опасная предаварийная
ситуация после нажатия кнопки АЗ-5, произведенного по команде начальника
смены для остановки реактора, перешла в первую стадию аварийного процесса,
обусловленного разгоном образовавшегося в нижней части активной зоны
зонального неконтролируемого реактора (подумать только: нажатие кнопки
аварийной защиты АЗ-5 - кнопки спасения - вызывает взрыв реактора)>.
При этом проявил себя третий принципиальный просчет в конструкции
стержней A3 и вообще всех стержней-поглотителей - малая скорость их введения
в активную зону при немыслимо большом полном времени погружения 18...20 с.
В то же время, как в нижней части создан реактор с большой
надкритичностью и нейтронная мощность в нем начала резко возрастать,
поглотители еще далеко. За время их движения нейтронная мощность успевает
реализоваться в тепловую (для специалистов - тепловая постоянная времени
твэлов 10 с). И здесь уже проявляет себя паровой эффект реактивности - вода
в технологических каналах превращается в пар, что ведет опять же к
возрастанию реактивности и увеличению мощности. Всплеск нейтронной мощности
мог привести к вскипанию воды и в каналах СУЗ и также к увеличению
реактивности. Так проектантами были выбраны характеристики реактора.
<Выбор столь неудачных, по сути дела опаснейших физических
характеристик, особенно при работе реактора на малом уровне мощности,
по-видимому, был сделан для достижения более выгодных экономических
показателей>.
--- http://lib.ru/MEMUARY/CHERNOBYL/dyatlow.txtи если ещё не устали -- то до того, как нашёл её, вот ещё наковырял изюму:
---
В такой вот деловой будничной обстановке реактор РБМК-1000 четвертого
блока ЧАЭС был взорван кнопкой аварийной защиты (!?!?).
[...]
26 апреля 1986 г. мы нажали кнопку АЗ при нормальных параметрах,
стабильном режиме, в отсутствие аварийных и предупредительных сигналов -
получили взрыв.
[...]
Ну, при АЗ со скоростью действия 18...20 с (чемпион по
медленнодействию) даже при нормальной конструкции стержней СУЗ говорить об
обосновании безопасности при положительном мощностном коэффициенте не
приходится.
Аналогично и требование другого нормативного документа - ПБЯ-04-74.
Можно констатировать. Имеем свидетельство Главного конструктора о
знании, как делать безопасный реактор. Имеем требование нормативных
документов. Сделано наоборот.
[...]
Перечисленные факты показывают, что в проекте реакторной установки не
были выполнены важнейшие требования пунктов 2.2.2. и 2.3.7. ОПБ.
Это единственная комиссия, которая отметила несоответствие реактора
нормативным документам. Правда, что-то ей помешало, возможно недостаток
времени., установить ставшие совершенно явными после аварии несоответствия
реактора коренным требованиям ПБЯ, но если бы этот документ был принят к
рассмотрению, то все требования нормативных документов по безопасности
реакторов, которым реактор не отвечал, выявились бы сами собой.
[...]
По мнению комиссии, реактор РБМК в том виде, в каком он был в 1986 г.,
вполне пригоден для эксплуатации. Для суда такое заключение вполне пригодно,
для жизни - нет. Поэтому немедленно на оставшихся реакторах РБМК после
аварии началась модернизация. Шедевром судебно-технической комиссии является
следующая формулировка: <вытеснение воды в нижних частях каналов СУЗ
могло внести дополнительную положительную реактивность, предусмотренную в
проекте>. Вот дают! Не ляпсус конструкторов, а их предусмотрительность!
[...]
Приведу выдержку из отчета А.А. Ядрихинского:
<В самом ИАЭ с 1965 г. были сотрудники И.Ф. Жежерун, В.П. Волков,
В.Л. Иванов, указывавшие на ядерную опасность предлагавшейся и впоследствие
осуществленной конструкции РБМК. Их действия успешно блокировались
академиком А.П. Александровым, а докладные клались <под сукно>.
Пуск и эксплуатация первого блока Ленинградской АЭС в 1975г. уже на
практике подтвердили ядерную опасность реакторов РБМК.
[...]
Ленинградская АЭС в 1975 г. только случайно избежала катастрофы
несколько иной по причинам, но аналогичной с Чернобылем по масштабам. В
результате локального перегрева зоны разгерметизировался технологический
канал. Но в той ситуации вполне могли разгерметизироваться три-четыре канала
одновременно, ведь на ремонте заменили около 20 штук. Как теперь ясно,
одновременный разрыв 3-4 каналов вел точно к Чернобылю.
[...]
На заседании секции впервые комиссией различных организаций было
признано большое (более 20) количество нарушений статей ПБЯ и ОПБ.
[...]
А вот это уже абсурд, нарушение всех норм проектирования. Конструкторы
допустили явную ошибку в конструкции стержней, когда при движении в одну
сторону они вносят реактивность разного знака. Сразу после аварии стержни
были признаны негодными всеми, включая авторов, но, удивительно,
конструкторы нашли поддержку экспертов.
--- http://lib.ru/MEMUARY/CHERNOBYL/dyatlow.txtа если действительно интересно -- то помимо точки зрения Дятлова стоит ещё почитать иные материалы на http://accidont.ru.
> git как всегда фейл, сколько бы не кричали git-фанбоиФэйл - это админ который безбашенно миррорит данные и мнит что это заменяет бэкап.
> git как всегда фейл, сколько бы не кричали git-фанбоиОно как пистолет. Если Вы прострелите себе ногу своим пистолетом, то это только Ваши личные проблемы .... на данный момент Git в своем классе лучший, вопрос только в кривизне рук которые его используют ...
>> git как всегда фейл, сколько бы не кричали git-фанбои
> Оно как пистолет. Если Вы прострелите себе ногу своим пистолетом, то это
> только Ваши личные проблемы .... на данный момент Git в своем
> классе лучший, вопрос только в кривизне рук которые его используют ...ога только git это пистолет с ножным приводом, четырьмя сотнями переключателей, размытой мушкой и дулом с рандомайзером, куда стрельнет в итоге не совсем ясно, более запутанную систему команд сложно было придумать. Но дык кто писал! Чел с явно выраженным NIH синдромом. Ах у вас команда checkout делает чекаут, так я тут немного исправлю пусть она хитро переключает ветки/коммиты, а еще пусть создает бранчи вместе с еще 100500 неочевидными результатами. собсно http://habrahabr.ru/post/174163/
Чувствуется глубокая обида и страдание. Не советую развивать эту тему ))
> мушкой и дулом с рандомайзером, куда стрельнет в итоге не совсем
> ясно, более запутанную систему команд сложно было придумать.То ли дело SVN - там если центральный сервак умрет, факап стопроцентный и фиг оспоришь. Получить копию репа с стороннего разработчика - вообще не вариант, история локально не хранится.
> собсно http://habrahabr.ru/post/174163/
Цитирую:
"Поскольку Git является мощной системой, не все программисты с первого раза понимают что это, и как это работает"
Бедные индусы и быдлокодеры - им сложно пользоваться серьезной тулзой от матерых системщиков. Надо что-нибудь попроще, от братьев по разуму.
> "Поскольку Git является мощной системой, не все программисты с первого раза понимают
> что это, и как это работает"Это отмазка. Чем лучше спроектирована система, тем больше всего она умеет и тем одновременно она проще для использования. В общем, git есть куда расти в плане понятности консольного интерфейса.
> Бедные индусы и быдлокодеры - им сложно пользоваться серьезной тулзой от матерых
> системщиков. Надо что-нибудь попроще, от братьев по разуму.Высококвалифицированный спец с более удобным и предсказуемым инструментом сделает больше, нежели с менее удобным (при том, что инструменты одного класса). И если ему приходится гуглить вместо того, чтобы логичным образом самому построить команду, вы тратите его драгоценное время.
Вообще да, но это не о гите. Он вполне логичен, если идти не от команд, а от архитектуры. То есть для того, кто таки читает инстукцию перед использованием - сплошной профит. Гуглить там потом есть смысл только на тему "а как еще интересно можно выгнуть гит, чтобы получить остроумный результат". А в данном случае - косяк документации, без вопросов. О том, что при использовании clone --mirror не производится проверка целостности, в мане писать надо большими буквами.
> Вообще да, но это не о гите. Он вполне логичен, если идти
> не от команд, а от архитектуры.На мой взгляд, идти нужно от команд. Тогда будет работать инкапсуляция: архитектуру VCS с какими-то целями поменяли, а команды остались те же. Поэтому именно команды, которые идут от предназначения инструмента, и есть самое важное.
> То есть для того, кто
> таки читает инстукцию перед использованием - сплошной профит.Желательно, чтобы инструкция была проста и незамысловата. Чем проще, тем больше таких инструкций сможет прочесть и запомнить спец. Тем больше
> Гуглить там потом есть смысл только на тему "а как еще интересно можно выгнуть
> гит, чтобы получить остроумный результат".Я бы не сказал, что удаление ветки в удалённом репозитарии - это выгибон. А делается командой push! Т.е. команда push названа неудачно.
> А делается командой push! Т.е. команда push названа неудачно.а по-моему, вполне логично. проталкивает изменения? проталкивает. а уж какие именно — не важно, хоть полное удаление всего, включая ОС и железо.
Ну вот комментарий arisu хорошее подтверждение важности понимания архитектуры. В данном случае - того, что мы храним не код, а _изменения_. И думаем мы именно б измнениях. И как по мне - если какая-то не интуитивная архитектура (а модель описания, понятно, к ней прибита) позволяет более эффективно работать - её и надо брать.Вот о том же индексе aka staging area подумать - если в терминах версий и хранимого кода - вообще не понять, что это. А если в терминах изменений - то вот именно изменения, готовые для сохранения в репозитории, индекс и хранит, всё сразу становится прозрачным.
вот кстати да. мне как-то изначально было очень просто думать именно об *изменениях*. наверное, поэтому гит и «пошёл» сразу. то есть, я никак по-другому про эти штуки и не думал вообще.
> Вот о том же индексе aka staging area подумать - если в
> терминах версий и хранимого кода - вообще не понять, что это.
> А если в терминах изменений - то вот именно изменения, готовые
> для сохранения в репозитории, индекс и хранит, всё сразу становится прозрачным.Это должно быть, в таком случае, написано везде большими красными буквами. Но вот мы читаем git-push(1):
git-push - Update remote refs along with associated objects
Ну что это за хрень? Какие refs? Какие objects?
Это первая строка man страницы, из неё должно быть понятно неофиту о чём речь. Возьмём sed(1):
sed - stream editor for filtering and transforming text
Всё чётко - фильтрация и преобразования текста.
Читаем описание git-push(1) - Description:Updates remote refs using local refs, while sending objects necessary to complete the given refs.
You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack(1).
Опять масло-маслянное (первая строка). Вторая же написана в стиле "цирк уехал, а клоуны остались". Теперь берём тот же sed(1):
Sed is a stream editor. A stream editor is used to perform basic text transformations on an input stream (a file or input from a pipeline). While in some ways similar to an editor which permits scripted edits (such as ed), sed works by making only one pass over the input(s), and is consequently more efficient. But it is sed's ability to filter text in a pipeline which particularly distinguishes it from other types of editors.
Опять таки понятно, что он делает - нормальная аннотация к программе.
ну да, маны к гиту написаны скорее как remainder'ы, нежели как manual'ы. в общем-то, недостаток относительный: у авторов гита позиция такая, что man используется именно как напоминалка для того, кто уже знает, и не заменяет документацию. можно ругаться, можно переписать маны, можно принять как есть. я, например, принял — потому что учишь один раз, а напоминалка нужна часто. и тогда термины «ref» и «associated object» мало того, что имеют смысл, так ещё и кратко, но адекватно описывают действия.
> Это отмазка. Чем лучше спроектирована система, тем больше всего она умеет и
> тем одновременно она проще для использования.Просто стили мышления индивидов могут отличаться. Как вы уже наверное могли заметить. И вот тут такое дело: если ваш стиль мышления более-менее совпал с стилем мышления программера, пользоваться тулзой легко и приятно. Она просто как влитая. Вы на уровне интуиции знаете что и где. Но для этого вам надо мыслить так как разработчик.
А вот это уже не факт. Люди бывают разные. И стили мышления у них разные. У академиков - один. У хомяков - другой. У системшиков - третий. Ну и так далее. Вопрос, соответственно, в том насколько мышление совпало. А универсального всеобщегр рецепта очевидного юзер интерфейса - нет. Очевидный интерфейс - только мамкина грудь. Остальному придется учиться. Вопрос скорее в том сколько учиться. И тут опять зависит не только от тулзы но и от стиля мышления индивида и его (не)совпадения с мышлением тех кто это программил.
> В общем, git есть куда расти в плане понятности консольного интерфейса.
Возможно, идеал на то и идеал чтобы к нему стремиться. Но лично я установив гит смог им пользоваться практически не читав манов. Он вполне логично делает свою работу. Так как мне хотелось бы ее видеть, особенно если это в команде. Да, для этого надо быть хоть немного прогрммистом и понимать как выглядит workflow в распределенной команде разработчиков. Тогда все станет просто, логично и понятно.
> Высококвалифицированный спец с более удобным и предсказуемым инструментом сделает больше,
> нежели с менее удобным (при том, что инструменты одного класса).Высококвалифицированный спец отдает себе отчет в своих действиях. А вот использовать некую фичу для бэкапа, при том что человек даже толком не знает что она делает - это никак не стиль работы квалифицированного специалиста. Квалифицированные специалисты таки изволят узнать как работает механика применяемая для сбора бэкапов. И задумываются над вопросом "а что будет, если".
> Просто стили мышления индивидов могут отличаться. Как вы уже наверное могли заметить.
> И вот тут такое дело: если ваш стиль мышления более-менее совпал
> с стилем мышления программера, пользоваться тулзой легко и приятно. Она просто
> как влитая. Вы на уровне интуиции знаете что и где. Но
> для этого вам надо мыслить так как разработчик.Мозг человеческий, в том числе и мой, легко перепрограммируется под правильный стиль мышления. Нужно только чётко, очень чётко показать, какие опорные точки, что есть сущности, что есть действия.
Товарищи CrazyAlex и arisu подсказали, что в git сущность - "изменения", а не "ревизии". Т.е. рассказали про не очень замысловатую внутреннюю логику. А вот создатель руководства git, которое я читал, этого не сделал. Т.е. сделал на отъ..сь и потратил груду времени высоквалифицированных спецов, вынужденных догадываться о "внутренней логике Git".
> Очевидный интерфейс - только мамкина грудь. Остальному придется учиться.
Да, но чтобы эффективно учиться, нужен хороший учитель. Например, руководство. В случае git man-page крайне плоха. К этому и претензии. А вот для sed - хороша.
> Да, для этого надо быть
> хоть немного прогрммистом и понимать как выглядит workflow в распределенной команде
> разработчиков. Тогда все станет просто, логично и понятно.Это явно неправда, т.к. есть ряд моих знакомых, уж явно хороших программистов, плюющихся от Git. Например, вот http://kouzdra.livejournal.com/643422.html
Куздра, между прочим - это мегапрофи. Если ему "унутренняя логика Git" неочевидна, то в консерватории явно не то.
> Высококвалифицированный спец отдает себе отчет в своих действиях. А вот использовать некую
> фичу для бэкапа, при том что человек даже толком не знает
> что она делает - это никак не стиль работы квалифицированного специалиста.А никто не говорит, что админы KDE не накосячили. Тем не менее, надо понимать, что система Git ввела их в заблуждение. Значит в неё нужно поставить "защиту от дурака".
> А вот создатель руководства git, которое я читал, этого не сделал. Т.е.
> сделал на отъ..сь и потратил груду времени высоквалифицированных спецов, вынужденных догадываться
> о «внутренней логике Git».ну так это… значит, явно помощь требуется. ну, например, в виде статьи «думаем как git» или подобного. я вот не напишу — потому что я изначально так думал. а ты по обе стороны был, отчего бы?..
> Куздра, между прочим — это мегапрофи.
это некомпетентный болван, с треском болван. примерно как наш изя, только чуть поумнее. если что — я не по приведённой ссылке сужу, я его далеко не один год знаю.
> Значит в неё нужно поставить «защиту от дурака».
я вот тебя тут перестаю понимать. ну, стоит же защита: те самые маны, которыми ты так недоволен. в плане того, что если человек там ничего толком не понял, то ведь не станет же он есть кактус и использовать такой непонятный инструмент? ан нет, всё равно просачиваются.
>[оверквотинг удален]
>> ясно, более запутанную систему команд сложно было придумать.
> То ли дело SVN - там если центральный сервак умрет, факап стопроцентный
> и фиг оспоришь. Получить копию репа с стороннего разработчика - вообще
> не вариант, история локально не хранится.
>> собсно http://habrahabr.ru/post/174163/
> Цитирую:
> "Поскольку Git является мощной системой, не все программисты с первого раза понимают
> что это, и как это работает"
> Бедные индусы и быдлокодеры - им сложно пользоваться серьезной тулзой от матерых
> системщиков. Надо что-нибудь попроще, от братьев по разуму.man git только на китайском или на древнеегипетчких символах!?
> man git только на китайском или на древнеегипетчких символах!?Отнюдь:
NAME
git - the stupid content tracker
Поскольку аноним является мощным коллективом, то не все читатели с первого раза понимают смысл их постов.Всё гениальное - просто. Всё сложное - не нужно. Если я программист, то это не значит, что я должен это делать в гамаке и стоя.
> Всё гениальное - просто. Всё сложное - не нужно. Если я программист,
> то это не значит, что я должен это делать в гамаке и стоя.В гамаке и стоя - это без git/hg. Ну если непонятны команды git, ну используйте вы hg или fossil, те же яйца, только без силы Линуса "Я всегда прав, а в этот раз я прав, как никогда" Торвальдса.
мне непонятны команды git. Использую hg. И по сравнению с hg, git - гамак.
> мне непонятны команды git. Использую hg. И по сравнению с hg, git - гамак.По сравнению с hg, git - это то же самое. Я видел.
> По сравнению с hg, git - это то же самое. Я видел.У буратины последние пару дней прямо приступы адеквата какие-то. А я уж думал что ему совсем башню сорвало...
> мне непонятны команды git.Он системщиками делался, а не гламурными кисами. Если мыслить как подобный програмер в распределенной команде - все получается на отлично. А если как гламурное кисо - тогда, конечно, ой. Hg для вторых поближе. Там для гламурных кис, которые cannot into commandline даже гуйнюшки какие-то сватают.
Похоже вы больше специалист по кошкам.
> Ах у вас команда checkout делает чекаут, так я тут немного исправлю пусть она хитро
> переключает ветки/коммитыНу хоть немного бы подумали (а не знаете -- так почитали) о том, по каким объектам действия производятся. Нет, это не чевеэсные ревизии.
А такой случай упустили, сесть и переписать весь KDE... С нуля! Чтобы не говорили, мол, "эти глюки из-за тех старых пердов, что писали KDE3"
Эх...
Несерьёзно как-то для проекта такого уровня.
И эти люди учат НАС ковыряться в носу .... хорошо, что хорошо кончается .... но эта новость отлично показывает, что авось и разгильдяйство присущи всем .... ИМХО - после такой шутки пора намекнуть админам, что ЗП они получают зря ... надо посмотреть на имена "героев"
> ЗП??
>> ЗП
> ??А разве они работают за идею ? По крайней мере пару core админов на full time должно быть ... это ж киокс
> А разве они работают за идею ?Хорошо бы утверждавшему про ЗП хоть чем-то подтвердить свои слова -- я бы скорее исходил из отсутствия ставки админа как таковой по умолчанию (AZ и другие уже всё по косточкам грамотно разобрали выше).
>> А разве они работают за идею ?
> Хорошо бы утверждавшему про ЗП хоть чем-то подтвердить свои слова -- я
> бы скорее исходил из отсутствия ставки админа как таковой по умолчанию
> (AZ и другие уже всё по косточкам грамотно разобрали выше).Моя же мысль страдала от недосказанности - постараюсь высказать более развернуто. Суть в том, что так или иначе ответственные за вопрос допустили крутой технологический ляп ... отсюда вывод о их квалификации в вопросе, за который они взялись или им поручили. То есть это люди, которые не способны овладеть вопросом на эл. уровне ... теперь вспоминаем, что есть OpenSource и каковы основные мотивы лиц, уч. в нем. Кроме получения удовольствия, это крупный пиар. Только в этом случае - пиар обратный. Если в этом случае они не смогли адекватно обеспечить работу public service (по сути спасло только чудо), то как они относятся к основным задачам в своей работе ? Давайте попробуем себя поставить на место их работодателей ...
Ляп не такой уж крутой - по факту если б опция --mirror была документирована как следует - её просто никто не использовал бы для резервного копирования, и никаких проблем не было бы. Ну и, по факту, фейл не такой уж страшный, как тут в статье расписали - поискать пришлось бы день-другой, но, скорее всего, особых проблем не было бы - наверняка уж кто-нибудь имеет нормальные версии.А если вывести за скобки то, что у них не проверялась целостность гитом (о чем они явно не знали) - то всё нормально организовано - есть куча копий, что тут ещё резервировать?
> Если в этом случае они не смогли адекватно обеспечить работу
> public service (по сути спасло только чудо)Ну вспомните смерть гентушной вики.
> то как они относятся к основным задачам в своей работе ?
Если работают над кодом, а не в администрёже -- то не шибко показательно, кстати.
> Давайте попробуем себя поставить на место их работодателей ...
Грамотные как раз знают, что за одного битого двух небитых дают. Ну, если в глазах появилось понимание набитых шишек.
Работать плохо за идею позорно в двойне.
> в двойнеможет всё-таки в близнецах?
да, подловил.
> И эти люди учат НАС ковыряться в носу .... хорошо, что хорошо
> кончается .... но эта новость отлично показывает, что авось и разгильдяйство
> присущи всем .... ИМХО - после такой шутки пора намекнуть админам,
> что ЗП они получают зря ... надо посмотреть на имена "героев"Не получают. Ни один из админов инфраструктуры KDE не получает за свою работу денег. Это пролетало где-то в их письмах (или постах?) на обсуждаемую тему.
Бог всё таки существует.
я хочу у них работать)) можно не думать даже
зеркалирование как способ бекапа. окееееей.[сообщение отредактировано модератором]
> зеркалирование как способ бекапа. окееееей.Зато много народа узнало что так делать не надо :)
не, не узнало. Многие люди (читай, "айтишники") не учатся даже на своих ошибках, что уж говорить о чужих.
>зеркалирование как способ бекапа. окееееей.предлагаете как то валидировать то что отзеркалировалось?
я например только сейчас слышу что оказывается git clone --mirror может возвращать мусор
Вообще, с трудом верится, что нельзя было в гите найти точку начала по времени разрушения данных (git checkout + log date). Хотя с другой стороны если зафиксировано разрушение - то доверять репе уже нельзя + эмоции разработчиков, и тем не менее - легко сделать git diff other-branch. Гит настолько мощный и устойчивый инструмент, что разумеется защита от дурка реализована ослабленной т.к. это не даст делать умные вещи. Но, думаю после этого случая гит улучшат касаемо опции mirror (никогда не пользовался, теперь буду знать про грабли)Анализируя данную ситуацию с гитом можно сделать вывод: делать из распределенной системы централизованную - крайне небезопасно (синдром кормления мышек и кактусом). Пример уже история со случившимся. Вот к чему приводит централизованное мышление. Если бы это был какой-нибудь централизованный svn - было бы еще хуже.
а про инкрементный бекап, как и про вообще системы бекапирвоания, мсье, вообще не в курсе?"централизованное мышление" блин :) детский садик.
дядя, а вы в курсе вообще в чем практический смысл разницы VCS и DVCS?
Гражданин наверное имеет отдаленное понятие об администрировании систем?
Может гражданину подтянуть тему?Хотя, что ожидать от опенсорца. Все же на коленке делается. Какие такие бекапы, будем тупо зеркалировать. Или что еще лучше - каждому сервису поручим следить за целостностью данных самостоятельно. Они же должны уметь, правда? :)
> Хотя, что ожидать от опенсорца. Все же на коленке делается.Можно поинтересоваться, чем Вы лично бэкапите важные данные? Скажем, с bacula оно по ненаколеночности сопоставимо?
PS: ну и вспоминаем, что админы делятся на... :)
бакула вполне годная системався штука в том, что там у них ничего не было. Даже "на скриптах за 5 минут" (С)
> вся штука в том, что там у них ничего не было.Видимо, не было понимания значения временнОй оси в вопросах создания и применения копий информации... ну да после такого "пронесло" оно обычно хорошо закрепляется ;-)
по русски это называется "пока гром не грянет.." ))
>> Хотя, что ожидать от опенсорца. Все же на коленке делается.
> Можно поинтересоваться, чем Вы лично бэкапите важные данные? Скажем, с bacula
> оно по ненаколеночности сопоставимо?
> PS: ну и вспоминаем, что админы делятся на... :)Разница не в том, что одна система наколенная, другая подколенная, а третья суперколенная.
Главное, когда последний раз очередная резервная копия была проверена на корректность!
Себе напомнил.
Угу, инкрементный бекап инкрементного бекапа... Проще надо быть. Собственно, если б эти не выпендривались и просто писали git clone/pull, как все и всегда делают - не было бы у них никаких особых проблем, заметили бы повреждение сразу. А раз полезли в экзотические опции - надо их изучить. Хотя здесь в документации, конечно, рповал адский. Мне бы тоже в голову не пришло, что можно использовать для копирования интерфейс гита и не получить проверку целостности. И ведь в мане ни слова, при выполнении команды - тоже...
> Угу, инкрементный бекап инкрементного бекапа... Проще надо быть.такая простота хуже воровства, что мы и видим на текущем примере. Они сочли, что нада еще проще.
еще раз - они как раз полезли что-то выдумывать вместо использования самого очевидного варианта git clone/git pull --all
Они как раз никуда не полезли. Даже за простым советом у студента-одмина.
> Они как раз никуда не полезли.Нет, они полезли втыкать какие-то ключи, сами фиг знает зачем. Ну и поплатились за это. Бывает и хуже - некоторые вон например за несколько киловольт хватаются. Потом другим приходится обугленные тапки убирать.
> Гит настолько мощный и устойчивый инструмент
>защита от дурка реализована ослабленнойТы вообще читаешь, что пишешь?
эта ваша феррари полный отстой - купил себе для пробы и решил на дачу съездить... застрял в луже... в общем делайте выводы...
Вот и ещё одни админы узнали, что зеркало != бэкап. Поздравления.
черти шо творится
http://wiki.winehq.org/ - не работает
http://torrents.freebsd.org:8080/ - не работает
> http://torrents.freebsd.org:8080/ - не работаетне знаю, как кто, а я уже даже не помню когда качал диск и ставил FreeBSD, обновляюсь через бинарное обналение, кому оно надо, не могу понять
действительно, совершенно не понятно: кому надо ставить FreeBSD
> кому оно надо, не могу понятьСудя по тому что оно в дауне - никому не надо. Как минимум из админов. Раздавать такого мамонта через новомодные торенты - неприемлимый авангардизмЪ.
>> кому оно надо, не могу понять
> Судя по тому что оно в дауне - никому не надо. Как
> минимум из админов. Раздавать такого мамонта через новомодные торенты - неприемлимый
> авангардизмЪ.и только бравые ребятЫ из того_самого_дистрибутива могут уже на след. день выкладывать новые iso`шки, которые на болванку [уже] помещаются, которые [уже] вообще бутабельные на, наполняя простаиващие каналы Очень Ценным Трафиком.
p.s. в последний раз качал iso фряхи еще во время 8-current, последнюю которую пришлось ставить _с нуля_ была 10ка, меньше месяца назад. iso не качал. но Продвинутым Пользователям Линукса это, видимо, кажется Шаманством ( установка без болванки/флешки).
> и только бравые ребятЫ из того_самого_дистрибутива могутМожем. А Вы -- нет.
> но Продвинутым Пользователям Линукса это, видимо, кажется
> Шаманством ( установка без болванки/флешки).Кластер удобней накрывать по PXE (когда оно работает в нужном сегменте), а вот один тазик несколько быстрей залить с флэшки, чем поднимать/подправлять dhcpd/tftpd/nfsd. Особенно когда второго тазика рядом нет.
Кстати, вменяемое начальство таких переделов, которые пытаются всё сделать максимально сложным образом (а то ведь корона упадёт!) вместо технологичного и поддерживаемого -- заменяет здравыми людьми. Надеюсь, у Вас вменяемое и урок когда-то пойдёт на пользу.
>> и только бравые ребятЫ из того_самого_дистрибутива могут
> Можем. А Вы -- нет.конкретно про ваш Очень Нужный Кому-То альт речи не шло, но если и он "может" то "гыгы"
>> но Продвинутым Пользователям Линукса это, видимо, кажется
>> Шаманством ( установка без болванки/флешки).
> Кластер удобней накрывать по PXE (когда оно работает в нужном сегменте), а
> вот один тазик несколько быстрей залить с флэшки, чем поднимать/подправлять dhcpd/tftpd/nfsd.покажи где речь шла о "кластер"
> Особенно когда второго тазика рядом нет.и только в этом случае нужен этот самый носитель, да. вот этого случая у меня уже годами как и не было. а что, есть сложности с "поднимать/подправлять dhcpd/tftpd/nfsd." ?
а да, боюсь что, находясь где-то в глухой тайге, тебе точно нафиг не нужно будет инсталлировать на тот_единственный_"тазик" ось.> Кстати, вменяемое начальство таких переделов, которые пытаются всё сделать максимально
> сложным образом (а то ведь корона упадёт!) вместо технологичного и поддерживаемого
> -- заменяет здравыми людьми. Надеюсь, у Вас вменяемое и урок
> когда-то пойдёт на пользу.а этот пассаж распарсить я не смог, про что речь?;) кто-то что-то переделывает, заменяет, пойдет.
Михаил, пора уже написать коронное "я тут болею [снова]" и отойти от клавиатуры, вместо того чтобы бред писать. ага?
>>> и только бравые ребятЫ из того_самого_дистрибутива могут
>> Можем. А Вы -- нет.
> конкретно про ваш Очень Нужный Кому-То альт речи не шлоТогда стоило конкретизировать, поскольку тот же я почувствовал в свой адрес некоторый упрёк (и то сказать -- заколебал уже народ упоминаниями своих вечнозелёных сборок, поди -- btw сегодня очередная :).
>> Кластер удобней накрывать по PXE (когда оно работает в нужном сегменте)
> покажи где речь шла о "кластер"Написал как конкретный пример. По сути мало отличается от серверной фермы и других знакомых случаев, когда применение сетевой установки по времени и усилиям оправдано.
>> Особенно когда второго тазика рядом нет.
> и только в этом случае нужен этот самый носитель, да.Вообще-то нет, если совсем припёрло -- в некоторых случаях ещё можно пытаться выкрутиться и стоя на иголке (когда-то доводилось исполнять танцы с loadlin из-под доса). Но лучше до такого не доводить.
> а что, есть сложности с "поднимать/подправлять dhcpd/tftpd/nfsd."?
Бывают, когда dhcpd на чём-то обрезанном или кривом. Например, на не умеющей нужных опций железке (было такое в старом офисе, пришлось перетаскивать) или на винде (а такое было у одного из заказчиков, там грузили тонкие клиенты).
> а да, боюсь что, находясь где-то в глухой тайге, тебе точно нафиг
> не нужно будет инсталлировать на тот_единственный_"тазик" ось.Всяко бывает -- помимо инсталяции, ещё и спасательные операции доводится изредка (и почти всегда неожиданно, дёргают-то по факту) проводить.
Вчерась случайно заметил, что экземпляр regular-rescue утащили в cisco -- как думаете, они там точно не умеют сетевую загрузку?
> Михаил, пора уже написать коронное "я тут болею [снова]"
:)
Ладно, как скажете. "С нашей стороны пуля вылетела".
> Тогда стоило конкретизировать, поскольку тот же я почувствовал в свой адрес некоторый
> упрёк (и то сказать -- заколебал уже народ упоминаниями своих вечнозелёных
> сборок, поди -- btw сегодня очередная :).ну я альт не видел что-то в районе 10 лет. раз не вижу и не слежу за развитием - не пишу про него, jfyi ;-)
>>> Особенно когда второго тазика рядом нет.
>> и только в этом случае нужен этот самый носитель, да.
> Вообще-то нет, если совсем припёрло -- в некоторых случаях ещё можно пытаться
> выкрутиться и стоя на иголке (когда-то доводилось исполнять танцы с loadlin
> из-под доса). Но лучше до такого не доводить.ну правда же, 2013 год на дворе. все больше и больше вещей переходит в разряда "нихерасебе, как они так жили вообще". в том смысле, что.. сложно представить _сейчас_ подобное.
>> а что, есть сложности с "поднимать/подправлять dhcpd/tftpd/nfsd."?
> Бывают, когда dhcpd на чём-то обрезанном или кривом. Например, на не
> умеющей нужных опций железке (было такое в старом офисе, пришлось перетаскивать)
> или на винде (а такое было у одного из заказчиков, там
> грузили тонкие клиенты).т.е. нечто обрезанное или кривое и 1 "голый" комп. так бывает?:-) про винду не помню уже. очень уж давно не видел dhcpd на ней, скорее всего, мне просто везет так.
> Всяко бывает -- помимо инсталяции, ещё и спасательные операции доводится изредка (и
> почти всегда неожиданно, дёргают-то по факту) проводить.у меня для этого есть usb брелок с head, опять-же, для развертывания на него системы iso мне не нужен был [это так, возвращаясь к начальной теме ветки].
> Ладно, как скажете. "С нашей стороны пуля вылетела".ну вот и ладненько:-)
Я представил это... Сегодня у KDE второй день рождения )
О! Они собираются перейти на ZFS )))"We could use ZFS on git.kde.org the same way it’s being used on the projects.kde.org box. ZFS has checksumming that detects errors both at the hardware and filesystem level (it is designed to operate on the very valid assumption that disks and memory are, or are going to go, bad; it’s relatively famous for detecting bad hardware that had previously been bit-flipping data silently for years). Its RAID-Z mechanism doesn’t suffer from the RAID Write Hole, it has excellent read performance given decent enough RAM, and it supports cheap Copy-on-Write snapshotting. The total size of all KDE Git repositories is about 25GB; it wouldn’t take a ton of space to make snapshotting directly on the server provide a decent benefit. I’d love to see this in use, but, after having had excellent experiences with it on Linux for a couple of years, I’m a ZFS fanboy at this point; and, I don’t know how well it’s supported on SUSE, which is the distribution git.kde.org is running (although I’ve run it on Gentoo, Debian, and Ubuntu without any problems)."
"could" - это ни разу не "собираются", а "могли бы использовать". По-нормальному использовать гит, как мне кажется, "несколько" проще. Особенно если делать на clone каждый раз, а таки pull.
> О! Они собираются перейти на ZFS )))дай дураку стеклянную ФС, он и файлы побьет, и руки порежет :(((
> дай дураку стеклянную ФС, он и файлы побьет, и руки порежет :(((И потом будут как тот фрукт на лисяре, когда вся эта махина у них завалится с треском.
>Главной ошибкой проектирования стало излишнее доверие первичному серверу git.kde.org, который воспринимался в качестве эталонного и в итоге стал единой точкой отказа.А нечего из гита свн делать!
> Дело в том, что для резервного копирования
> применялась практика зеркалирования Git-репозитория.ахтыж... и эти вот люди будут запрещать мне ковыряться в носу?
мне казалось, что даже последний опеннетовский анонимоус понимает, что зеркалирование и бэкап - это не муж и жена, а четыре разных человека. а поди ж ты.
В чём проблема, не пойму, у каждого разработчика полная копия репозитория со всей историей. Гиту сервер не нужен вообще.
> В чём проблема, не пойму, у каждого разработчика полная копия репозитория со всей историей. Гиту сервер не нужен вообще.Для коллективной разработки Git нужен центральный репозиторий, с которым все заинтересованные разработчики синхронизируют изменения из своих локальных репозиториев. В данный момент они ссинхронизировались с битым центральным репозиторием и получили битые данные в своих локальных репозиториях. Вопрос в том, почему это произошло, почему запущенный git pull не смог отследить повреждённые данные и импортировал в локальные репозитории разработчиков ересь, что они не смогли ничего восстановить? Почему нашлась только одна неповреждённая копия репозитория?
> Для коллективной разработки Git нужен центральный репозиторий,Не центральный, а любой, который является точкой обмена. Можно хоть ftn-структуру выстроить с нодами и пойнтами, главными и неглавными.
> с которым все заинтересованные
> разработчики синхронизируют изменения из своих локальных репозиториев. В данный момент
> они ссинхронизировались с битым центральным репозиторием и получили битые данные в
> своих локальных репозиториях.Этого не может быть.
> почему запущенный git pull не смог отследить повреждённые данныеМожно ссылочку?
> Для коллективной разработки Git нужен центральный репозиторий,Пиндеж, это лишь один из возможных вариантов на выбор.
> они ссинхронизировались с битым центральным репозиторием и получили битые данные в
> своих локальных репозиториях.Пруф? Там только про развал бэкапов говорится, которые синкались с очень специфичным недефолтным ключом, т.к. у админа зудело пощелкать опциями. Пощелкал. Оказалось что одна маленькая опция в руках раздолбая может принести довольно много вреда.
> git pull не смог отследить повреждённые данные и импортировал
А импортировал? Пруф? Он только понаделал битых зеркала тем раздолбаям которые его с --mirror пинали. Тут вообще двойной продолб - малопонятно почему парни решили что mirror это вообще бэкап. И кроме того они не удосужились узнать как работает поюзанная ими фича. Что как бы раздолбайство.
> И кроме того они не удосужились узнать как работает поюзанная ими фича. Что как бы раздолбайство.Узнать из кода, по-видимому?
Резервная копия должна хранится автономно! (С)Аксиома
У них система упала, а они не удосужились проверить целостность Фс перед подключением сервера а зеркало?
Если админы затеяли обнову сервера при работающем зеркале? А вывести, а потом отзеркалить как вновь подключенный?
Децентрализованная система. По ревизиям вжик-вжик. svn - хахаха. а по факту коснись что - "а у кого рабочая версия"? ну и естественно никто эту версию проверять не будет. у нас все свои, мы всем доверяем. ладно хоть обошлось.
> у нас все свои, мы всем доверяем.…и поэтому подписываем коммиты, например. а кто не подписывает — тот ССЗБ.
> …и поэтому подписываем коммиты, например. а кто не подписывает — тот ССЗБ.У этих, которых никогда ничего не сыпется, не виснет и не хакается - на секурити, интегрити и прочая по жизни просто клали. Фанбои и так хавают, а не фанбои выводы давно уже сделали и свинтили оттуда кто куда.
Супер-пупер система Git таки сильно разрослась и растолстела. У меня вообще есть ощущение, что всё новые и новые опции для команд появляются потому, что кому-то было лень думать, как свою задачу выполнить серией вызовов уже имеющихся команд, и этот кто-то тупо нахачивает что-то в исходниках, отсылает, это нечто проходит аппрувы и попадает в апстрим.
По пути теряются неочевидные вещи, типа проверки целостности -- ведь тестировал чувак без этого геморроя, а проверяющие и вовсе забыли...
Я в целом ничего не имею против Git и сам им пользуюсь параллельно с Mercurial, но в отличие от последнего у Гита как-то подозрительно много подозрительно ненужных команд и опций. Кто знает, что ещё где потеряли при нахачивании новой "фичи"...
> подозрительно много подозрительно ненyжных команд и опций."Если мне не нyжно, значит никому не нyжно". Стандартная логика макинтошного хомяка.
А вы знаете, намного лучше если редкая опция нужная раз в год, после дождика в четверг все-таки окажется в программе. Иначе придется ее самому дописывать или как-то еще ужасно костылить. И вот это будет конкретный залет. Вместо того чтобы заниматься своим делом - оказывается надо карандаши точить и кисточки покупать. И вот уже проект встал колом...
не понимаю о чем вообще эта новость. git clone --mirror не проверяет целостность того что копируется? они сделали clone и стерли старые бекапы? так?git fetch после git clone --mirror проверила бы целостность удаленного репозитария или в любом случае git fsck необходим?
git clone --mirror может вернуть мусор.ВОПРОС: git fetch может вернуть мусор?
>чудомЧудес не бывает - бывают только криворукие мудaки и чётные ошибки.
Т.е. эти "администраторы" делают резервные копии каждые 20 минут, при этом не сохраняя старых - недельных, за месяц?
> Т.е. эти "администраторы" делают резервные копии каждые 20 минут,Хуже. Они делают зеркала и думают что это - типа, резервная копия.
эх. такое отличное событие испортили.
Да, без проверки клонирование быстрее. А если копию записывать в /dev/null - быстродействие ошеломляющее.
> Да, без проверки клонирование быстрее. А если копию записывать в /dev/null -
> быстродействие ошеломляющее.Вот как раз КДЕ именно туда и надо бекапировать. Они просто это ниасилили.
> А если копию записывать в /dev/null - быстродействие ошеломляющее.Да вот у кедовского админа руки видимо не дошли заоптимизировать свое "бэкапирование" чуть дальше.
> Да, без проверки клонирование быстрее. А если копию записывать в /dev/null -
> быстродействие ошеломляющее.На медни _отлаживал :-| копирование из /dev/zero в /dev/null, так замахался с ключами dd и прочими пайпами, чтоб получить не 63Мб/с, а 547, или даже 808. И при том, чтоб "записалось" столько же _байтов, сколько было подано на вход.
...а вы говорите, git.
+++Бросил, у "клиента" всё работает"зашибись".
откатились бы на КДЕ 3.5, невелика беда.
да нормальный git бекап ))
надо просто было делать по крону 'git clone' в отдельные папки по дням недели (было б 7 копий в неделю), хотя имхо лучше с этим справиться rsync
https://github.com/progman/git_backup
Что то меня этот момент в GIT сильно смутил. Я как-то больше с SVN работаю, а там физически нереально ни при зеркалировании, ни при иной репликации удалить ревизию. То есть, разрушение какого-то репозитория, конечно могло привести к удалению файлов в последней ревизии. Но это лечилось бы просто откатом на предыдущую.