Вот что мне не нравится в git:
Прежде всего, я думаю, что распределенная идея бросает вызов реальности. Все, кто на самом деле использует git, делают это централизованно, даже Линус Торвальдс. Если бы ядро управлялось распределенным способом, это означало бы, что я не мог бы загрузить «официальные» исходники ядра — их бы не было — мне пришлось бы решать, хочу ли я версию Линуса или версию Джо, или версия Билла. Это, очевидно, было бы нелепо, и именно поэтому существует официальное определение, которым Линус управляет с помощью централизованного рабочего процесса.
Если вы соглашаетесь с тем, что вам нужно централизованное определение ваших вещей, тогда становится ясно, что роли сервера и клиента совершенно разные, поэтому догма о том, что клиентское и серверное программное обеспечение должны быть одинаковыми, становится чисто ограничивающим. Догма о том, что данные клиента и сервера должны быть одинаковыми, становится явно смешной, особенно в кодовой базе с пятнадцатилетней историей, до которой никому нет дела, но всем придется клонировать.
Что мы на самом деле хотим сделать со всеми этими старыми вещами, так это засунуть их в шкаф и забыть, что они там, как это делает любой нормальный VCS. Тот факт, что git таскает все это туда-сюда по сети каждый день, очень опасен, потому что вам нужно его обрезать. Эта обрезка включает в себя множество утомительных решений, и она может пойти не так. Таким образом, люди, вероятно, будут хранить целую серию репозиториев моментальных снимков из разных моментов истории, но разве не для этого изначально был создан контроль версий? Этой проблемы не существовало, пока кто-то не изобрел распределенную модель.
Git активно поощряет людей переписывать историю, и вышесказанное, вероятно, является одной из причин этого. Каждая нормальная система контроля версий делает переписывание истории невозможным для всех, кроме админов, и гарантирует, что у админов не будет причин об этом думать. Поправьте меня, если я ошибаюсь, но, насколько я знаю, git не дает возможности предоставить обычным пользователям доступ на запись, но запрещает им переписывать историю. Это означает, что любой злопамятный разработчик (или все еще борющийся с кривой обучения) может испортить всю кодовую базу. Как мы затянем это? Ну, либо делаешь регулярные бэкапы всей истории, т.е. держишь историю в квадрате, либо запрещаешь доступ на запись всем, кроме какого-нибудь бедняги, который будет получать все дифы по электронной почте и сливать их вручную.
Давайте возьмем пример хорошо финансируемого крупного проекта и посмотрим, как git работает для них: Android. Однажды я решил поиграться с самой системой Android. Я узнал, что должен был использовать кучу скриптов под названием repo, чтобы добраться до их git. Некоторые из репозиториев работают на клиенте, а некоторые на сервере, но оба сами своим существованием иллюстрируют тот факт, что git неполноценен в любом качестве. Случилось так, что я не мог получить исходники около недели, а потом вообще сдался. Мне пришлось бы вытащить огромное количество данных из нескольких разных репозиториев, но сервер был полностью перегружен такими людьми, как я. Время ожидания репо истекло, и его невозможно было возобновить с того места, где оно истекло. Если git настолько распространяемый, можно было бы подумать, что они сделали бы что-то вроде одноранговой связи, чтобы уменьшить нагрузку на этот единственный сервер. Git можно распространять, но это не сервер. Git+repo — это сервер, но репозиторий нельзя распространять, потому что это просто специальный набор хаков.
Аналогичной иллюстрацией неадекватности git является gitolite (и его предок, который, по-видимому, работал не так хорошо). Gitolite описывает свою задачу как упрощение развертывания сервера git. Опять же, само существование этой штуки доказывает, что git не сервер, а клиент. Более того, этого никогда не будет, потому что, если он перерастет в любой из них, это будет предательством его основополагающих принципов.
Даже если бы вы верили в распределенную вещь, git все равно был бы беспорядком. Что такое, например, филиал? Говорят, что вы неявно создаете ветку каждый раз, когда клонируете репозиторий, но это не может быть то же самое, что ветка в одном репозитории. Итак, по крайней мере две разные вещи называются ветвями. Но затем вы также можете перемотать репо и просто начать редактирование. Это как второй тип ветки или опять что-то другое? Может быть, это зависит от того, какой тип репо у вас есть - о да - по-видимому, репо тоже не очень четкая концепция. Есть нормальные и голые. Вы не можете перейти к обычному, потому что пустая часть может не синхронизироваться с исходным деревом. Но вы не можете cvsimport на голую, потому что они не думали об этом. Таким образом, вы должны выполнить cvsimport в обычный, клонировать его в голый, который попали в руки разработчиков, и cvsexport в рабочую копию cvs, которую еще нужно проверить в cvs. Кого можно беспокоить? Откуда взялись все эти сложности? Из самой распространенной идеи. В конце концов я отказался от гитолита, потому что он накладывал на меня еще больше этих ограничений.
Git говорит, что ветвление должно быть легким, но у многих компаний уже есть серьезная проблема с мошенническими ветками, поэтому я подумал, что ветвление должно быть важным решением со строгим контролем. Вот где perforce действительно сияет...
На самом деле вам редко нужны ветки, потому что вы можете очень гибко манипулировать наборами изменений. Например, обычный рабочий процесс заключается в том, что вы синхронизируетесь с последней известной исправной версией в основной ветке, а затем пишете свою функцию. Всякий раз, когда вы пытаетесь изменить файл, разница этого файла добавляется в ваш «набор изменений по умолчанию». Когда вы пытаетесь зафиксировать набор изменений, он автоматически пытается объединить новости из основной ветки с вашим набором изменений (эффективно перемещая его), а затем фиксирует. Этот рабочий процесс применяется без необходимости его понимания. Таким образом, Mainline собирает историю изменений, которую вы можете легко просмотреть позже. Например, предположим, что вы хотите вернуть старый, скажем, позапрошлый. Вы синхронизируете с моментом перед оскорбительным изменением, помечаете затронутые файлы как часть набора изменений, синхронизируете с моментом после и объединяете с «всегда моим». (Там было кое-что очень интересное: синхронизация не означает наличие одного и того же — если файл доступен для редактирования (т. е. в активном наборе изменений), он не будет затерт синхронизацией, а помечен как подлежащий разрешению.) Теперь у вас есть список изменений, который отменяет оскорбительный. Объединитесь с последующими новостями, и у вас будет список изменений, который вы можете добавить поверх основной ветки, чтобы получить желаемый эффект. Мы никогда не переписывали историю.
Теперь, предположим, на полпути к вам подбегает кто-то и говорит вам бросить все и исправить какую-нибудь ошибку. Вы просто даете своему списку изменений по умолчанию имя (фактически число), затем «приостанавливаете» его, исправляете ошибку в теперь пустом списке изменений по умолчанию, фиксируете его и возобновляете именованный список изменений. Обычно несколько списков изменений приостанавливаются одновременно, когда вы пробуете разные вещи. Это легко и конфиденциально. Вы получаете то, что действительно хотите, от режима ответвления без соблазна откладывать или уклоняться от слияния с основной веткой.
Я полагаю, что теоретически возможно сделать что-то подобное в git, но git делает практически все возможным, а не утверждает рабочий процесс, который мы одобряем. Централизованная модель представляет собой набор допустимых упрощений по сравнению с распределенной моделью, которая является недопустимым обобщением. Он настолько обобщен, что в основном ожидает, что вы внедрите систему управления версиями поверх него, как это делает репо.
Другое дело репликация. В git все возможно, так что вы должны сами во всем разобраться. Фактически вы получаете кэш без сохранения состояния. Единственная конфигурация, которую ему нужно знать, это где находится мастер, и клиенты могут указывать либо на мастера, либо на кеш по своему усмотрению. Это пятиминутная работа, и она не может пойти не так.
У вас также есть триггеры и настраиваемые формы для проверки кода, ссылки на багзиллы и т. д., и, конечно же, у вас есть ветки, когда они вам действительно нужны. Это не ясно, но близко, и его очень легко настроить и поддерживать.
В общем, я думаю, что если вы знаете, что собираетесь работать централизованно, как все делают, вы могли бы также использовать инструмент, который был разработан с учетом этого. Git переоценен из-за устрашающего остроумия Линуса и склонности людей ходить друг за другом, как овцы, но его основной смысл существования на самом деле не выдерживает здравого смысла, и, следуя ему, git связывает себе руки с две огромные догмы о том, что (а) программное обеспечение и (б) данные должны быть одинаковыми как на клиенте, так и на сервере, и это всегда будет усложнять и усложнять централизованную работу.
person
Adrian May
schedule
21.06.2012
