|
|
| (не показаны 2 промежуточные версии 2 участников) |
| Строка 1: |
Строка 1: |
| − | [[Image:Linus-git-googletalk.0-00-04.098.jpg|right]] | + | #REDIRECT [[Линус Торвальдс о GIT на Google Talks]] |
| − | | + | |
| − | <blockquote>
| + | |
| − | Перевод доклада Линуса Торвальдса о системе контроля версий <tt>git</tt> на «''Google Talk''»
| + | |
| − | <ref>Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8</ref>,
| + | |
| − | выполнен сообществом компании [http://team.custis.ru «Заказные ИнформСистемы»].
| + | |
| − | </blockquote>
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk.0-00-11.269.jpg|center]]
| + | |
| − | [[Категория:Системы контроля версий]]
| + | |
| − | | + | |
| − | == Представление ==
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk.0-00-19.731.jpg|framed|right| Эндрю Мортон. Один из ведущих разработчиков ядра Linux. Работник Google]]
| + | |
| − | | + | |
| − | '''''Эндрю:'''''
| + | |
| − | Спасибо всем пришедшим, большинство из вас вероятно уже слышали
| + | |
| − | о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях.
| + | |
| − | Это парень, который прется от издевательств над людьми.
| + | |
| − | Его последняя выходка — создание СУВ<ref>система управления версиями</ref>, которая явно создана для того,
| + | |
| − | чтобы вы почувствовали себя менее умными, чем до знакомства с ней.
| + | |
| − | Спасибо, что снизошли до нас сегодня, Линус.
| + | |
| − | Последние дни я получал письма от людей, вопрошающих:
| + | |
| − | «Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | <!-- [[Image:Linus-git-googletalk.0-00-35.640.jpg|framed|center]] -->
| + | |
| − | И вот, он пришел в мой офис сегодня днем, и сказал: «а чем ты вообще тут занимаешься?!»
| + | |
| − | О, спасибо вам, что тратите на нас свое время.
| + | |
| − | И вот, Линус пришел сегодня, чтобы объяснить нам,
| + | |
| − | какого …, он написал такие тулы, гм,
| + | |
| − | что только он тот избранный, кто настолько мудр, чтобы понять, как ими пользоваться.
| + | |
| − | | + | |
| − | [[Изображение:linus-git-googletalk.0-00-51.199.jpg|framed|center| тут все апплодируют, апплодируют…]]
| + | |
| − | | + | |
| − | == Вводное слово ==
| + | |
| − | [[Изображение:linus-git-googletalk.0-01-15.165.jpg|framed|left|Линус Торвальдс.]]
| + | |
| − | | + | |
| − | '''''Линус:'''''
| + | |
| − | | + | |
| − | Ну, я должен слегка предостеречь вас, что я не очень хороший оратор,
| + | |
| − | частично потому, что я не люблю выступать, а частично потому,
| + | |
| − | что за последние несколько лет все только и хотели от меня докладов
| + | |
| − | о туманном будущем Линукса в следующем столетии, | + | |
| − | а я вообще гик и предпочитаю говорить о технологиях.
| + | |
| − | | + | |
| − | Так вот, я не буду говорить про ''Ядро''<ref>Проект Linux Kernel.</ref>, просто потому, что оно слишком большое,
| + | |
| − | чтобы рассказать о нем за час, хотя похоже Эндрю сделал это пару дней назад.
| + | |
| − | Вместо этого я расскажу вам про [[EnPedia:Git_(software)|git]], систему управления версиями,
| + | |
| − | которую мы используем для Ядра.
| + | |
| − | | + | |
| − | Я очень-очень-очень плохо делаю слайды, поэтому,
| + | |
| − | если я буду строго им следовать, то к концу вы все умрете от тоски.
| + | |
| − | Видимо, в любом случае доклад сильно удачным не будет,
| + | |
| − | но я из тех докладчиков, которые действительно рады отвечать на вопросы.
| + | |
| − | В общем, если мы будем местами отклоняться от плана доклада,
| + | |
| − | то всем нам будет лучше, вероятно и разговор у нас получится более интересный.
| + | |
| − | | + | |
| − | <!-- [[Изображение:linus-git-googletalk.0-01-10.219.jpg|framed|right]] -->
| + | |
| − | Я не знаю, как тут у вас, на ''Google talks'', все это происходит,
| + | |
| − | я скажу просто — меня не стесняйтесь.
| + | |
| − | А если ваш начальник потом вас пристрелит — это будет уже ваша проблема.
| + | |
| − | | + | |
| − | == Credits ==
| + | |
| − | | + | |
| − | [[Изображение:Linus-git-googletalk.0-02-21.683.jpg|framed|Потому что Линус любит заставлять людей думать, что он скромный|left]]
| + | |
| − | Сначала я хочу раздать несколько отзывов и благодарностей.
| + | |
| − | | + | |
| − | О [[CVS]] я будут отзываться только в очень-очень отрицательном ключе,
| + | |
| − | потому что я, когда проектировал <tt>git</tt>, во многих ситуациях
| + | |
| − | использовал (в контексте СУВ) подход «что бы тут сделал Иисус», а иногда и «что бы тут CVS никогда не сделала».
| + | |
| − | | + | |
| − | Я никогда не использовал CVS при разработке ядра.
| + | |
| − | За последние десять лет для поддержки ядра
| + | |
| − | мы использовали только тарболы<ref>tarballs — несжатые tar-архивы</ref>
| + | |
| − | и патчи<ref>patch — файлы изменений</ref>,
| + | |
| − | которые оказались лучшими СУВ, чем CVS,
| + | |
| − | но я «покончил с CVS» после семилетнего опыта использования ее
| + | |
| − | в коммерческой компании, и я страстно ненавижу эту систему.
| + | |
| − | | + | |
| − | Когда я сказал, что страстно ненавижу CVS, я должен также сказать, что если в аудитории есть пользователи SVN ([[EnPedia:Subversion (software)|Subversion]]),
| + | |
| − | то вы, возможно, захотите уйти.
| + | |
| − | Поскольку моя ненависть к CVS означает, что я считаю Subversion самым
| + | |
| − | бесцельным проектом, так как основной девиз Subversion некоторое время был
| + | |
| − | «Сделанный по-уму CVS» или что-то вроде этого.
| + | |
| − | А если вы начинаете с такого слогана, то вы никуда не сможете прийти.
| + | |
| − | Это так, потому что CVS невозможно сделать «правильным».
| + | |
| − | | + | |
| − | Это была негативная часть.
| + | |
| − | | + | |
| − | А вот с благодарностью я упомяну о [[EnPedia:BitKeeper|BitKeeper]],
| + | |
| − | хотя я понимаю, что по мнению многих, вокруг ''BitKeeper''’а было
| + | |
| − | много проблем и споров да и «развод» с ним был во многих смыслах неприятен.
| + | |
| − | Но по-моему, наш развод с BitKeeper-ом был
| + | |
| − | вполне полюбовный, хотя снаружи это казалось иначе.
| + | |
| − | И BitKeeper не только стал первой системой контроля версий,
| + | |
| − | которая показалась мне вполне достойной,
| + | |
| − | но, более того, показал мне, в чем была его основная идея
| + | |
| − | и как с ней можно реально работать.
| + | |
| − | И хотя <tt>git</tt> во многом, в том числе технически, очень-очень сильно отличается от
| + | |
| − | BitKeeper (это было специально задумано, чтобы убедить всех, что это
| + | |
| − | не клон BitKeeper), многие процессы используемые нами с <tt>git</tt>,
| + | |
| − | взяты из BitKeeper.
| + | |
| − | | + | |
| − | Кстати, вы используете BitKeeper здесь, в Google? Я сомневаюсь.
| + | |
| − | Насколько я знаю, BitKeeper — это единственная коммерческая распределенная СУВ,
| + | |
| − | и поэтому, если вам-таки нужна именно коммерческая система,
| + | |
| − | то вам стоит использовать BitKeeper.
| + | |
| − | | + | |
| − | Я также хотел бы заметить, что я разрабатываю <tt>git</tt> чуть больше двух лет,
| + | |
| − | но хотя я запустил проект, разработал архитектуру и начальный код,
| + | |
| − | на протяжении последних полутора лет его поддерживает
| + | |
| − | гораздо более славный парень, японец ''Junio Hamano'',
| + | |
| − | и именно он сделал <tt>git</tt> более доступным для простых смертных.
| + | |
| − | Ранние версии <tt>git</tt> действительно требовали некоторое количество
| + | |
| − | «ментальных пунктов» мозгосилы.
| + | |
| − | C тех пор он стал гораздо проще.
| + | |
| − | | + | |
| − | В общем, это мой обычный подход —
| + | |
| − | все остальные делают все возможное, а я сам могу просто сидеть и потягивать
| + | |
| − | ПинаКоладу<ref>Пинья колада (исп. Piña colada), также ошибочно называемый пинаколада/пиноколада и т. п. — традиционный карибский алкогольный коктейль содержащий ром, кокосовое молоко и ананасовый сок.</ref>,
| + | |
| − | ну и типа люди то же вроде как-то при деле…
| + | |
| − | | + | |
| − | На этом благодарности окончены, всех вышеперечисленных откладываем в сторону.
| + | |
| − | | + | |
| − | == Content ==
| + | |
| − | | + | |
| − | [[Изображение:linus-git-googletalk.0-06-23.653.jpg|framed|right| Он набросал эту презентацию прошлой ночью, не ждите здесь чуда]]
| + | |
| − | Вот этому слайду уже один день.
| + | |
| − | Я вообще не делал презентацию прошлой ночью, потому что прошлой ночью
| + | |
| − | я пьянствовал, отрывался и ел суши. Вот.
| + | |
| − | | + | |
| − | И тем не менее, в презентации
| + | |
| − | речь пойдет о реализации надежной, высокопроизводительной распределенной
| + | |
| − | системы управления содержимым, и ключевое слово здесь — «распределенная».
| + | |
| − | Я сначала попытаюсь объяснить, почему распределенность так важна.
| + | |
| − | Если мы потом к этой теме не вернемся, я буду действительно счастлив.
| + | |
| − | | + | |
| − | И ничего страшного, если мы так и не разберем, как <tt>git</tt> устроен изнутри.
| + | |
| − | Учить пользоваться <tt>git</tt>’ом я тоже не буду.
| + | |
| − | Ну есть же у вас такая штука, которую вы делаете, «google.com»,
| + | |
| − | и в ней есть такое место, куда можно вводить буквы, и если вы введете туда «git»
| + | |
| − | и нажмете кнопку «Мне повезет!», вы обязательно попадете [http://git-scm.com/ на официальный сайт <tt>git</tt>],
| + | |
| − | на котором есть и вводные обучающие курсы и руководство пользователя в HTML-формате.
| + | |
| − | В общем, если вы хотите научиться пользоваться <tt>git</tt>, вам нужно первым делом туда,
| + | |
| − | а не на этот доклад.
| + | |
| − | | + | |
| − | Но, как я уже сказал, ничего страшного, если мы отклонимся в сторону от темы
| + | |
| − | из-за ваших вопросов.
| + | |
| − | | + | |
| − | == Content Advisory ==
| + | |
| − | [[Изображение:Linus-git-googletalk.0-08-05.443.jpg|framed|left|Линус критичен и к программам и к людям]]
| + | |
| − | | + | |
| − | Я вам уже озвучил эти примечания к заголовкам; я использую сокращение [[EnPedia:Source_Code_Management|SCM]] в
| + | |
| − | значении «''source code management''/управление исходным кодом»,
| + | |
| − | что то же самое, что контроль версий. Некоторые думают, что SCM означает
| + | |
| − | «Управление конфигурациями/''software configuration management''»
| + | |
| − | и включают сюда не только контроль версий, но и управление релизами и все такое;
| + | |
| − | но я сейчас буду рассказывать не об этом, хотя <tt>git</tt> вполне подходит и для этого.
| + | |
| − | | + | |
| − | С [[CVS]] мы уже разобрались. Вы можете не соглашаться со мной сколько хотите, но в течение этого доклада
| + | |
| − | все, кто не согласен со мной, по определению — тупые уроды.
| + | |
| − | Помните об этом!
| + | |
| − | Вы будете вольны делать и думать все что захотите, когда я закончу доклад.
| + | |
| − | А сейчас я рассказываю свое единственно правильное мнение,
| + | |
| − | так что пользователи CVS, если вы действительно его так любите,
| + | |
| − | уйдите с глаз моих долой. Вам надо обратиться в психушку или куда-то еще.
| + | |
| − | | + | |
| − | == Background ==
| + | |
| − | [[Изображение:Linus-git-googletalk.0-09-24.327.jpg|framed|right|от BitKeeper к <tt>git</tt>]]
| + | |
| − | | + | |
| − | Теперь, перед тем как начать говорить о самой сути «Распределенности»,
| + | |
| − | что, по-моему, архиважно, нельзя не упомянуть об истории <tt>git</tt>,
| + | |
| − | потому что если люди что-то и слышали о <tt>git</tt>,
| + | |
| − | то это, в первую очередь, историю его возникновения.
| + | |
| − | | + | |
| − | Во-первых, я на самом деле вообще не фанат SCM.
| + | |
| − | Я никогда особо не интересовался системами контроля версий, и думал, что это зло,
| + | |
| − | пока не наткнулся на ''BitKeeper'', который оценил по достоинству; и,
| + | |
| − | в некотором смысле, именно поэтому <tt>git</tt> намного лучше всего остального,
| + | |
| − | ведь мой мозг не страдал долгие годы, думая, что [[CVS]] делает что-либо разумное.
| + | |
| − | | + | |
| − | Мне понадобилась замена для BitKeeper.
| + | |
| − | Причина в том, что BitKeeper — это коммерческий продукт,
| + | |
| − | но ''BitMover'' и ''Larry McVoy'' разрешили использовать его бесплатно для open-source
| + | |
| − | продуктов, как вы, возможно, знаете; единственным ограничением было то,
| + | |
| − | что его нельзя было исследовать (''reverse engineer'') и нельзя пытаться создать конкурирующий продукт.
| + | |
| − | | + | |
| − | И я был вполне этим доволен, ведь я делаю свободное ПО,
| + | |
| − | потому что считаю это единственным правильным способом разработки,
| + | |
| − | но я также хочу использовать лучшие инструменты для работы,
| + | |
| − | и BitKeeper был как раз таким.
| + | |
| − | | + | |
| − | Но не все были согласны со мной.
| + | |
| − | Все они тупые уроды, но как бы там ни было,
| + | |
| − | они подкинули проблем,
| + | |
| − | и это в результате привело к тому, что мы с ''Larry'' несколько раз
| + | |
| − | поговорили по телефону и в конце концов договорились прервать сотрудничество,
| + | |
| − | дабы не ухудшать отношения.
| + | |
| − | | + | |
| − | Тогда, примерно 2 года назад, я выпустил релиз <tt>Linux 2.6.12-rc2</tt> и сказал,
| + | |
| − | что не продолжу разработку Linux, пока у меня не будет замены BitKeeper’у,
| + | |
| − | для управления исходным кодом.
| + | |
| − | | + | |
| − | Одним из способов замены был возврат к tar-архивам и патчам,
| + | |
| − | но все были категорически против.
| + | |
| − | | + | |
| − | Поэтому я рассмотрел кучу альтернатив.
| + | |
| − | Большинство из них я отбросил, даже не попробовав.
| + | |
| − | | + | |
| − | Если система не распределенная, ее не стоит использовать, это же очевидно.
| + | |
| − | | + | |
| − | Если у системы проблемы с производительностью,
| + | |
| − | ее тоже не стоит использовать, это так же очевидно.
| + | |
| − | И наконец, если вы не можете быть уверенными в том, что то, что вы положите в SCM,
| + | |
| − | можно легко достать обратно в том же виде,
| + | |
| − | такую систему тоже лучше не использовать.
| + | |
| − | | + | |
| − | Честно говоря, та малышка [BitKeeper] прекрасно заботилась обо всем.
| + | |
| − | Полно СУВ которые не гарантируют, что то, что вы из них достаете,
| + | |
| − | является в точности тем, что в них положили.
| + | |
| − | Вы можете никогда и не узнать, что у вас повреждена память или жесткий диск.
| + | |
| − | А заметите это, только когда получите назад поврежденный файл.
| + | |
| − | Причем сама система контроля версий за этим вообще не следит.
| + | |
| − | И такое — совсем не редкость.
| + | |
| − | Да, это встречается очень, очень часто.
| + | |
| − | | + | |
| − | Проблема быстродействия: одной из систем, которая мне более-менее понравились,
| + | |
| − | была система [[EnPedia:Monotone_(software)|Monotone]], о которой, кстати, когда-то вроде был доклад в Google,
| + | |
| − | хотя может я и ошибаюсь; так вот, в ней было много интересных идей,
| + | |
| − | но производительность была просто ужасна,
| + | |
| − | так что попробовав ее один день, я понял, что она мне не подходит.
| + | |
| − | | + | |
| − | В результате, я решил, что сам за две недели смогу написать что-то получше,
| + | |
| − | и не ошибся.
| + | |
| − | | + | |
| − | == Distribution ==
| + | |
| − | | + | |
| − | [''Показывает слайд «Distribution» с картинкой'']
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk-slide-distribution.jpg|framed|Это не просто хорошая идея. По-другому просто не будет работать!]]
| + | |
| − | | + | |
| − | Теперь перейдем к ''Распределенности'', и это худший слайд из всех,
| + | |
| − | и мне стыдно за него, но проблема в том, что ''Распределенность''
| + | |
| − | действительно очень важна,
| + | |
| − | но у меня никогда не получается сделать об этом нормальный слайд.
| + | |
| − | Частично это из-за моих скудных художественных способностей,
| + | |
| − | которые вы видите перед собой на экране,
| + | |
| − | но на самом деле это действительно трудно объяснить.
| + | |
| − | | + | |
| − | Поэтому прежде чем я начну, я хотел бы знать,
| + | |
| − | кто из вас привык к идее по-настоящему распределенной системы контроля версий?
| + | |
| − | | + | |
| − | [''слушатели поднимают руки'']
| + | |
| − | | + | |
| − | Большинство из вас разрабатывают ядро?
| + | |
| − | Нет?
| + | |
| − | Хорошо, примерно десять человек подняли руки.
| + | |
| − | | + | |
| − | Распределенность главным образом означает отсутствие центрального места,
| + | |
| − | в котором хранятся ваши данные и отслеживаются изменения.
| + | |
| − | Ни одно хранилище не является более важным, чем какое-либо другое.
| + | |
| − | | + | |
| − | Поэтому, например, я Subversion даже
| + | |
| − | трехметровым багром трогать не буду.
| + | |
| − | В Subversion большой репозиторий, куда все обязаны складывать свои данные.
| + | |
| − | А централизованная модель просто не работает,
| + | |
| − | когда… давайте взглянем на некоторые такие случаи.
| + | |
| − | | + | |
| − | [''Показывает слайд «Distribution» с пунктами'']
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk-slide-distribution2.jpg|frame|Слайд «Distribution» с пунктами]]
| + | |
| − | | + | |
| − | Я сказал, что распределенность — это гораздо больше, чем просто работа в оффлайн,
| + | |
| − | но это, пожалуй, понять проще всего:
| + | |
| − | вы можете взять по-настоящему распределенную SCM с собой в самолет и,
| + | |
| − | даже если в нем нет ни wi-fi, ни спутникового интернета,
| + | |
| − | вы просто продолжаете работать — вы можете посмотреть любые логи,
| + | |
| − | вы можете фиксировать изменения, вы можете делать все, что вы бы делали,
| + | |
| − | если бы вы были подключены прямо к магистральному каналу с гигабитным Ethernet.
| + | |
| − | И это действительно важно.
| + | |
| − | | + | |
| − | Это вдвойне важно, когда над одним и тем же проектом работают
| + | |
| − | сотни и тысячи людей, и они даже не обязательно должны быть все отключены
| + | |
| − | от сети, просто на практике они на самом деле не всегда имеют хорошую связь.
| + | |
| − | Так что работа в оффлайн — это один из аспектов распределенности,
| + | |
| − | и даже если работа не всегда идет оффлайн,
| + | |
| − | очень важно иметь возможность делать все, что вам нужно,
| + | |
| − | находясь в любом месте и даже не имея возможности подключиться к серверу.
| + | |
| − | | + | |
| − | Этот простой факт приводит к появлению гораздо большего количества веток,
| + | |
| − | потому что каждый, у кого есть целиком весь репозиторий и возможность в него
| + | |
| − | коммитить, будет работать в своей собственной ветке, даже этого не осознавая.
| + | |
| − | Да-да, даже если вы считаете, что ваш проект имеет только одну ветвь, каждый раз,
| + | |
| − | когда вы отключаетесь от сети и начинаете работать над проектом,
| + | |
| − | вы работаете со своей отдельной веткой.
| + | |
| − | | + | |
| − | И это действительно очень важно и очень сильно отличается от работы в CVS,
| + | |
| − | где ветвление считается уделом настоящих мастеров.
| + | |
| − | | + | |
| − | Кто из вас когда-либо пользовался CVS?
| + | |
| − | | + | |
| − | [''Слушатели поднимают руки'']
| + | |
| − | | + | |
| − | Понятно, все. А кто когда-нибудь по-настоящему создавал ветку, а потом объединял изменения в CVS?
| + | |
| − | | + | |
| − | [''Слушатели поднимают руки'']
| + | |
| − | | + | |
| − | Хорошо.
| + | |
| − | Отмечу, что далеко не все, хотя и гораздо больше, чем я ожидал.
| + | |
| − | | + | |
| − | Ну и кому из вас понравилось осуществлять этот процесс?
| + | |
| − | | + | |
| − | [''смех'']
| + | |
| − | | + | |
| − | Понятно, все-таки нескольким понравилось.
| + | |
| − | | + | |
| − | Считается, что это сложная операция. В CVS, когда вы объединяете ветки (а я делал это, избегал как мог, но приходилось),
| + | |
| − | вы планируете это на неделю вперед и, как правило, оставляете на это целый день.
| + | |
| − | | + | |
| − | Разве я не прав?
| + | |
| − | Что-то я не вижу, чтобы многие говорили «Нет, это очень просто, мне нравится это делать».
| + | |
| − | Это отвратительно!
| + | |
| − |
| + | |
| − | Обязательно нужно понять, что в распределенной системе каждый человек работает
| + | |
| − | со своей отдельной веткой.
| + | |
| − | И это не страшно, вам даже не надо что-то специально настраивать,
| + | |
| − | так устроено изначально.
| + | |
| − | | + | |
| − | На самом деле, в <tt>git</tt> мы так любим ветки, что многие держат их по 10-15 штук,
| + | |
| − | потому что когда вы понимаете, что у вас по-любому будет отдельная ветка,
| + | |
| − | вам уже все равно, сколько их будет, и вы делаете отдельные ветки
| + | |
| − | для экспериментов и отдельные для поддержки.
| + | |
| − | Так что ветвление гораздо более свойственно распределенным системам.
| + | |
| − |
| + | |
| − | Еще одна вещь, которая мне кажется важной, — это то, что распределенная система
| + | |
| − | в силу своего устройства более надежна.
| + | |
| − | | + | |
| − | Мой подход к архивам/бэкапам таков:
| + | |
| − | не делать их специально,
| + | |
| − | а просто публиковать свои данные на сайте,
| + | |
| − | а остальные пусть их копируют/зеркалируют, и мне пофиг,
| + | |
| − | если у меня сломается компьютер, потому что я могу скачать все обратно.
| + | |
| − | И это отлично работает, и при этом мне не нужна служба поддержки.
| + | |
| − | | + | |
| − | Я очень сомневаюсь, что все так делают.
| + | |
| − | Но это по-настоящему работает только в распределенных системах.
| + | |
| − | Если вы пользуетесь CVS, вы не можете так сделать, если вы используете…
| + | |
| − | кстати, чем вы здесь пользуетесь?
| + | |
| − | | + | |
| − | Perforce?… [[EnPedia:Perforce|Perforce]]. Ну да, извините.
| + | |
| − | Да, он, конечно же, лучше, чем [[CVS]].
| + | |
| − | | + | |
| − | [''Слушатели смеются'']
| + | |
| − | | + | |
| − | Но все равно это по сути CVS.
| + | |
| − | | + | |
| − | Еще одна прикольная вещь, хотя у вас в компании возможно этого и нет,
| + | |
| − | но это обязательно есть во всех командах, разрабатывающих свободное ПО,
| + | |
| − | которые используют CVS или Subversion или что-то вроде этого, это то,
| + | |
| − | что они пользуются понятием «commit access».
| + | |
| − | | + | |
| − | Ведь то, что у вас центральный репозиторий, означает, что все,
| + | |
| − | кто работают над проектом, должны складывать данные именно туда.
| + | |
| − | | + | |
| − | И что это значит?
| + | |
| − | Поскольку вы не хотите, чтобы все подряд правили данные в центральном
| + | |
| − | репозитории, из-за того, что большинство людей — идиоты, то вам приходится выделять
| + | |
| − | людей, которые, по-видимости, идиотами не являются.
| + | |
| − | И чаше всего в этой группе оказывается слишком мало людей, потому что очень
| + | |
| − | сложно понять, насколько человек шарит, и наоборот,
| + | |
| − | даже если эта группа будет очень мала,
| + | |
| − | проблемы у вас все равно будут.
| + | |
| − | | + | |
| − | В общем, эта проблема доступа к коммитам, которую некоторые компании
| + | |
| − | пытаются не замечать, просто давая всем доступ для коммитов, эта
| + | |
| − | проблема создает огромный психологический барьер и в большинстве проектов с
| + | |
| − | открытым кодом приходится тратить бесконечные часы для того, чтобы определиться
| + | |
| − | с политикой коммитов.
| + | |
| − | | + | |
| − | Если же у вас распределенная модель, всех этих проблем нет.
| + | |
| − | Доступ к коммитам есть у каждого, вы можете делать что угодно со своим проектом.
| + | |
| − | Вы просто получаете собственную ветвь, и пишете ли вы в ней гениальный код, или
| + | |
| − | какой-нибудь маразм, это никого не волнует, это ваша копия.
| + | |
| − | Это ваша ветвь.
| + | |
| − | | + | |
| − | И потом, если окажется, что вы сделали что-то полезное, вы можете сказать
| + | |
| − | людям: «''Эй, тут в моей ветви все работает в десять раз быстрее, чем у всех остальных,
| + | |
| − | так что ня-ня-ня, не хотите взять мой код?''».
| + | |
| − | И народ берет.
| + | |
| − | | + | |
| − | Так это и работает и у нас нет никаких правил.
| + | |
| − | Это конечно не совсем так — у нас регулируется другое,
| + | |
| − | но о таких вещах как доступ к коммитам нам беспокоиться не нужно.
| + | |
| − | И я думаю, что это огромный результат и уже только из-за него одного любая
| + | |
| − | система с открытым кодом должна использовать распределенную модель, а не
| + | |
| − | что-либо другое.
| + | |
| − | | + | |
| − | Вы избавитесь от кучи проблем.
| + | |
| − | | + | |
| − | Одна из них касается коммерческих компаний.
| + | |
| − | Распределенная модель может также помочь с процессом выпуска релизов.
| + | |
| − | У вас может быть команда тестировщиков, которая работает в своем дереве.
| + | |
| − | Они берут код у других, проверяют его и когда проверят, передадут его
| + | |
| − | команде выпуска.
| + | |
| − | И они скажут: «Эй, мы тут проверили новую версию» и разработчики могут
| + | |
| − | продолжать работать головой вместо того, что маяться всякой дурью типа создания
| + | |
| − | меток, ветвей и всего того, что вы обычно делаете, чтобы разработчики не
| + | |
| − | конфликтовали друг с другом, потому что это достигается тем, что каждая группа
| + | |
| − | работает в своем дереве, следит за тем, что она сделала и что хочет сделать.
| + | |
| − | | + | |
| − | То есть Распределенность — это на самом деле ключевой момент для любой из
| + | |
| − | СУВ, которые стоит использовать.
| + | |
| − | | + | |
| − | Так что немедленно избавьтесь от Perforce!
| + | |
| − | | + | |
| − | [''Апплодисменты'']
| + | |
| − | | + | |
| − | Да, может и жалко, но это архиверно!
| + | |
| − | | + | |
| − | Это был мой единственный слайд о распределенности.
| + | |
| − | Я бы хотел послушать ваши вопросы, потому что затем мы двинемся к другой теме.
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk.0-21-39.872.jpg|frame|right|И как вы собираетесь это делать?]]
| + | |
| − | | + | |
| − | {{question}} Вопрос. И как вы собираетесь это делать?
| + | |
| − | Если у вас есть эта монстрообразная, страшно огромная база кода
| + | |
| − | и вы хотите использовать ее, не останавливая
| + | |
| − | другие дела на шесть месяцев, как вы собираетесь это делать?
| + | |
| − | | + | |
| − | '''Линус:'''
| + | |
| − | | + | |
| − | Не отходите от микрофона, потому что я не совсем понял ваш вопрос.
| + | |
| − | Он ушел, ну ладно.
| + | |
| − | | + | |
| − | «Как вы собираетесь это делать?» — Ну, вот пример реальной распределенности:
| + | |
| − | у вас есть команда из пяти человек, которые работают над
| + | |
| − | одной небольшой конкретной вещью.
| + | |
| − | | + | |
| − | И это означает, что некоторое время это вещь будет сильно-сильно
| + | |
| − | испорчена, так?
| + | |
| − | Потому что никто на самом деле не создает прекрасный код с первого раза, за
| + | |
| − | исключением меня, но я такой один, так?
| + | |
| − | Поэтому им нужно иметь собственное дерево,
| + | |
| − | в котором они могут работать, не мешая остальным.
| + | |
| − | | + | |
| − | Вы можете этого достичь множеством способов.
| + | |
| − | В CVS один из наиболее распространенных подходов — не делать коммитов вообще,
| + | |
| − | поскольку возиться с ветвями очень нудно.
| + | |
| − | | + | |
| − | То есть вы не делаете коммиты, пока код не пройдет абсолютно все тесты.
| + | |
| − | Или например, в вашей компании строгое политика коммитов:
| + | |
| − | «нельзя делать коммиты пока они не пройдут весь набор тестов»,
| + | |
| − | а между прочим все тесты будут выполняться два часа, жесть!
| + | |
| − | | + | |
| − | Да, вам не позволяют делать коммиты.
| + | |
| − | И это происходит почти в каждой компании.
| + | |
| − | Я уверен, что это так даже у вас, в Google.
| + | |
| − | У вас вероятно есть строгий набор тестов и вам нельзя делать коммиты, пока
| + | |
| − | все тесты не будут пройдены, а это приводит к тому, что на практике люди вносят
| + | |
| − | изменения по одной строчке и не тестируют, потому что знают, что изменения в
| + | |
| − | одной строчке скорее всего ничего не сломают.
| + | |
| − | Да, бывает и так.
| + | |
| − | | + | |
| − | Такой подход, конечно — ужас-ужас!
| + | |
| − | Это означает, что вы делаете коммит огромного числа изменений за раз,
| + | |
| − | потому что работали над этими изменениями две недели.
| + | |
| − | И в итоге у вас три человека, которые делают одно и то же, потому
| + | |
| − | что они не видят изменений от других, пока не сделают коммит своих.
| + | |
| − | Это часто происходит, это происходит везде, это жуть!
| + | |
| − | | + | |
| − | Другой вариант — это использовать ветви, пусть даже в централизованной среде.
| + | |
| − | Но ветви всегда обрываются, так как их слишком дорого поддерживать,
| + | |
| − | так что у вас не получится разрабатывать в них экспериментальную функциональность.
| + | |
| − | Вы никогда заранее не знаете, потребуется ли на что-то один день или две недели,
| + | |
| − | ведь почти всегда любой программист скажет: «Ха, я сделаю это за 48 часов».
| + | |
| − | А потом выясняется, что «не-а, не могу».
| + | |
| − | | + | |
| − | Но так как вы думаете, что сможете сделать это за 48 часов, вам очень лень
| + | |
| − | создавать ветвь, даже в таких системах, в которых это делать удобнее, чем в CVS.
| + | |
| − | И вы этого не делаете, потому что думаете, что как-нибудь справитесь с этим
| + | |
| − | и вы возвращаетесь к случаю № 1, но даже если вы решите создать ветвь, то будете
| + | |
| − | менять содержимого репозитория и для всех остальных,
| + | |
| − | потому что в централизованной среде ветви глобальны.
| + | |
| − | | + | |
| − | То есть вы столь любезны, что вы трахаетесь со всеми остальными,
| + | |
| − | но при этом не трогаете их ''основной ствол'', так называемую ''головную ветвь''.
| + | |
| − | Вы добавляете что-то новое в их репозитории, но при этом так,
| + | |
| − | чтобы они ничего не заметили (по-крайней мере, вы на это надеетесь).
| + | |
| − | Но общий репозиторий все равно от этого пухнет.
| + | |
| − | | + | |
| − | В общем, в любом случае, успеха вы не добьетесь.
| + | |
| − | | + | |
| − | В распределенной же среде происходит так: есть пять человек, они берут себе
| + | |
| − | текущую головную ветвь, которая надежна и протестирована и они начинают
| + | |
| − | работать с ней и делать коммиты,
| + | |
| − | и вам не надо ждать две недели, пока ваши изменения не станут стабильными,
| + | |
| − | потому что они всегда локальны.
| + | |
| − | А внутри этой группы из пяти человек, все могут брать
| + | |
| − | изменения друг у друга.
| + | |
| − | | + | |
| − | Вот в этом и смысл распределенности — нет центра, а значит, что все
| + | |
| − | равны и что можно проводить слияния друг между другом, что можно, если хочется,
| + | |
| − | не только делать коммит каждой строчки, не проходя при этом
| + | |
| − | двухчасовые тесты, но и гибко взаимодействовать, забирая и сливая
| + | |
| − | изменения у кого и с кем угодно, и когда кто-то находит баг и
| + | |
| − | исправляет его, он говорит остальным:
| + | |
| − | «Эй, у меня в репозитории лежит фикс на этот баг», и потом,
| + | |
| − | когда эта группа все сделает через две недели, они
| + | |
| − | позвонят менеджеру:
| + | |
| − | «Эй, мы все сделали, скажи главной группе, чтоб они забрали
| + | |
| − | себе обновленный код и они получат новую функциональность, и, кстати, мы его
| + | |
| − | тестили больше двух недель, оно работает и с производительностью все в порядке,
| + | |
| − | так как мы смогли также и профилировать этот код до того,
| + | |
| − | как просить кого-либо его посмотреть».
| + | |
| − | | + | |
| − | И эта модель гораздо лучше для разработки.
| + | |
| − | | + | |
| − | И это модель, которая используется в разработке ядра Linux.
| + | |
| − | Оказывается, что во многих местах нам не нужна вся эта мощь, даже в ядре.
| + | |
| − | И люди обычно не обмениваются обновленным кодом внутри одной группы, но иногда
| + | |
| − | случается, например, что те, кто работает над сетью, иногда сталкиваются с
| + | |
| − | людьми, которые работают над NFS, и то, что они могут синхронизироваться,
| + | |
| − | действительно помогает.
| + | |
| − | То есть это действительно помогает!
| + | |
| − | | + | |
| − | У кого-то еще есть вопрос?
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk.0-27-03.671.jpg|frame|right|Похоже, что все эти правила и ограничения просто переместились или стали неявными.…]]
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | {{question}} Похоже, что все эти правила и ограничения просто переместились или стали неявными.
| + | |
| − | Да, у каждого есть доступ и все играются со своими ветвями в песочнице, но к вечеру
| + | |
| − | ветви нужно соединять и разрешать все конфликты чтобы не было 80
| + | |
| − | миллиардов вариантов каждого линуксового ядра.
| + | |
| − | | + | |
| − | '''Линус:'''
| + | |
| − | | + | |
| − | Да, именно так.
| + | |
| − | Но на практике вы их никогда не увидите, да там может быть тысяча или
| + | |
| − | двести тысяч различных ветвей, но на практике вы никогда о них не узнаете,
| + | |
| − | потому что вам это не нужно.
| + | |
| − | Вы как бы будете видеть только несколько главных ветвей, может быть даже
| + | |
| − | только одну.
| + | |
| − | | + | |
| − | Вот в случае с ядром, полно людей, которые смотрят только на мою ветвь,
| + | |
| − | так что несмотря на то что ветвей может быть очень много, вы можете не обращать
| + | |
| − | на это внимания.
| + | |
| − | И что важно, это способ, которым происходят слияния, он и определяет,
| + | |
| − | насколько все это будет безопасно и надежно.
| + | |
| − | | + | |
| − | Через сеть доверия.
| + | |
| − | | + | |
| − | Если вы когда-нибудь занимались какой-то работой по безопасности
| + | |
| − | и не использовали концепцию сети доверия, то это был онанизм,
| + | |
| − | а не работа.
| + | |
| − | Я не знаю, чем вы там занимались, но поверьте мне, это единственный способ,
| + | |
| − | который дает безопасность и также единственно верный подход
| + | |
| − | в разработке ПО.
| + | |
| − | | + | |
| − | В своей работе я не доверяю всем без исключения.
| + | |
| − | | + | |
| − | Более того, на самом деле я крайне циничен и недоверчив.
| + | |
| − | | + | |
| − | Я думаю, большинство из вас полностью некомпетентны.
| + | |
| − | | + | |
| − | Основной принцип распределенности — это то, что я не должен вам доверять.
| + | |
| − | Я не должен давать вам доступ к коммитам.
| + | |
| − | Но я знаю, что среди оравы середнячков есть несколько человек,
| + | |
| − | достаточно выдающихся, чтобы я им доверял, ибо с ними я уже работал.
| + | |
| − | | + | |
| − | Мне нужно доверять только 5, 10, ну может 15 людям.
| + | |
| − | Если у меня есть доверенная сеть, в которую входят эти 5, 10, 15 выдающихся
| + | |
| − | человек, и я знаю, что они выдающиеся, я могу забирать новый код
| + | |
| − | у них.
| + | |
| − | И мне не надо париться на эту тему.
| + | |
| − | | + | |
| − | Когда Эндрю присылает мне патчи, он не использует никакого <tt>git</tt>,
| + | |
| − | это в некотором роде недостаток, ну и что, он очень надежный человек.
| + | |
| − | Когда он просит меня принять обновленный код, он просто посылает мне
| + | |
| − | миллион патчей, я просто их применяю.
| + | |
| − | Иногда я не согласен с какими-то из этих патчей, но с другой стороны,
| + | |
| − | доверие означает, как это сказать… «доверять — значит прощать»? Я не знаю…
| + | |
| − | В общем, это означает, что вы должны соглашаться с решениями других людей.
| + | |
| − | | + | |
| − | И самое замечательное в доверии — это что оно создает сеть.
| + | |
| − | Именно здесь и появляется сеть доверия.
| + | |
| − | | + | |
| − | Мне нужно лишь несколько человек, которым я буду доверять.
| + | |
| − | А у них есть другие люди, которых они выбрали, типа — «тот парнишка шарит покруче
| + | |
| − | меня» — да, это хороший критерий того, от кого вам следует брать исправленный код.
| + | |
| − | Если у вас есть кто-то еще, кто шарит лучше вас, — вперед.
| + | |
| − | Это беспроигрышно.
| + | |
| − | | + | |
| − | Даже если окажется, что вы взяли какую-то чушь, кто-то там начнет
| + | |
| − | жаловаться, вы знаете, откуда вы взяли эти исправления, и вы можете просто
| + | |
| − | сказать это жалующемуся «хм, я просто скопировал это, иди к нему, он наверное знал, что делал».
| + | |
| − | | + | |
| − | [[Image:Linus-git-googletalk.0-30-08.466.jpg|frame|right|Именно так я и работаю…]]
| + | |
| − | | + | |
| − | Именно так я и работаю, скорее всего также действуют и мои поручики/заместители
| + | |
| − | <ref>В оригинале ''lieutenants'', поэтому часто в рунете помощников Линуса зовут «лейтенантами».</ref>.
| + | |
| − | Я забираю изменения по сетевой теме от одного человека, а он получает их от
| + | |
| − | множества других людей, с которыми он постоянно работает, и таким образом все
| + | |
| − | изменения приходят ко всем, и им не нужно собираться всем в одной точке.
| + | |
| − | | + | |
| − | Хотя в ядре все приходит в большей степени в одну точку, так, я думаю, сложилось
| + | |
| − | исторически, и на самом деле я всегда пытался поощрять пожелания людей заводить
| + | |
| − | больше деревьев, и у нас действительно есть отдельные деревья по производителям оборудования,
| + | |
| − | у нас есть специальное «-mm»<ref>Экспериментальная ветвь ядра Linux, специализированная на управлении памятью, см. [[EnPedia:Mm_tree]].</ref> дерево, в котором много выделенных «точек», просто так получается, что
| + | |
| − | моя точка привлекает, быть может, больше внимания, чем должна была бы.
| + | |
| − | | + | |
| − | Даже если что-то там не придет к этой одной точке, это значит, что
| + | |
| − | можно взять тысячи этих ветвей, игнорируя <tt>99.9%</tt> из них.
| + | |
| − | Зато вам интересно отслеживать, скажем пять ветвей, относящихся к областям, которыми вы интересуетесь.
| + | |
| − | | + | |
| − | И все это работает очень естественно.
| + | |
| − | | + | |
| − | Одной из хороших вещей в этой целой сети доверия,
| + | |
| − | является не только то, что ее легко технически реализовать,
| + | |
| − | но и то, насколько легко основательно подключить к ней
| + | |
| − | любого человека из этой комнаты.
| + | |
| − | | + | |
| − | Люди мыслят именно так.
| + | |
| − | | + | |
| − | Мы не знаем сотню людей.
| + | |
| − | У нас есть 5, 7, 10 близких личных друзей, ну ладно, пусть мы асоциальные гики,
| + | |
| − | поэтому у нас их двое, но это основы человеческого сотрудничества, то
| + | |
| − | что у нас есть те, кому мы действительно можем доверять,
| + | |
| − | это семья, это близкие друзья, и все это удобно и привычно, не нужно
| + | |
| − | держать в голове неестественную модель взаимодействия,
| + | |
| − | все подключаются естественным образом.
| + | |
| − | Поэтому работа с этой моделью сетевого доверия дает огромные преимущества.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.0-31-51.970.jpg|frame|right|Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?]]
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | {{question}} Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?
| + | |
| − | Похоже, тут есть вероятность «сепаратизма» в коде,
| + | |
| − | так как народ, разбредется по собственным песочницам, и
| + | |
| − | не будет вкладываться в основной ствол.
| + | |
| − | | + | |
| − | '''Линус:'''
| + | |
| − | | + | |
| − | Честно говоря, не так уж и много распределенных систем.
| + | |
| − | Это BitKeeper, очевидно использующийся коммерческими компаниями,
| + | |
| − | мы должны иметь в аудитории кого-нибудь, кто действительно знает, но что …
| + | |
| − | [''комментарий из аудитории''], ага,
| + | |
| − | HP использует такие системы как BitKeeper в проектах разработки принтеров.
| + | |
| − | | + | |
| − | Я уверен, что таких компаний немало.
| + | |
| − | В мире open-source ПО, есть пара распределенных
| + | |
| − | систем, которых стоит посмотреть прямо сейчас.
| + | |
| − | Очевидно одна из них — <tt>git</tt>.
| + | |
| − | И вы, конечно, должны выбрать ее.
| + | |
| − | | + | |
| − | Но есть и другая — Mercurial, которая на самом деле очень похожа по архитектуре.
| + | |
| − | Есть некоторые различия в деталях архитектуры и большие различия в реализации,
| + | |
| − | но в сухом остатке модели очень похожи.
| + | |
| − | Только <tt>git</tt> делает это лучше.
| + | |
| − | | + | |
| − | Все остальное либо централизованное, либо сырое, либо слишком медленное
| + | |
| − | для достаточно больших проектов.
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | {{question}} А какие преимущества у компании, когда все играются в собственных песочницах?
| + | |
| − | | + | |
| − | | + | |
| − | '''Линус:'''
| + | |
| − | | + | |
| − | Я думаю, что есть полно компаний, считающих, что такие преимущества есть.
| + | |
| − | | + | |
| − | Я знаю это от инсайдеров, и не думаю, что многие компании
| + | |
| − | осознанно используют <tt>git</tt>, в смысле, чтобы решение по его использованию
| + | |
| − | было принято на уровне корпоративного стандарта.
| + | |
| − | | + | |
| − | Я знаю несколько компаний, которые внутри
| + | |
| − | используют <tt>git</tt>, не подозревая об этом, потому что они все еще держат
| + | |
| − | свои главные репозитории в Subversion, но многие разработчики затем
| + | |
| − | импортируют код в <tt>git</tt>, потому что <tt>git</tt> действительно хорошо выполняет слияния.
| + | |
| − | Так что вы можете взять дерево веток из Subversion, импортировать в <tt>git</tt>,
| + | |
| − | позволить <tt>git</tt> сделать слияние,
| + | |
| − | что было бы основной головной болью в Subversion,
| + | |
| − | зафиксировать изменения и фактически экспортировать их назад в Subversion,
| + | |
| − | и никто другой даже не узнает, что вы использовали <tt>git</tt>.
| + | |
| − | Немного грустно, но я слышал о многих,
| + | |
| − | работающих в компаниях в точности по этому сценарию.
| + | |
| − | | + | |
| − | А вот чтобы постоянно использовать <tt>git</tt> подряд в течении полугода или больше — таких людей пока еще мало.
| + | |
| − | | + | |
| − | Мы сделали масштабные улучшения пользовательских интерфейсов,
| + | |
| − | честно говоря, еще год назад в коммерческих компаниях
| + | |
| − | многие говорили, что его слишком трудно использовать.
| + | |
| − | | + | |
| − | Я думаю, что мы прошли переломный момент.
| + | |
| − | Git намного проще использовать, чем CVS, правда-правда!
| + | |
| − |
| + | |
| − | Большинство людей склоняются к … э-мнэ-э, он проще в использовании, чем что-либо еще.
| + | |
| − | Это всего лишь,… забудьте это.
| + | |
| − | Вы не обязаны использовать все его мощные возможности,
| + | |
| − | некоторые из них могут
| + | |
| − | быть тем, что вы хотели бы объяснить и представить людям только
| + | |
| − | после того, как они преодолеют начальные трудности
| + | |
| − | понимания того, что действительно означает распределенность,
| + | |
| − | но основные вещи делать действительно легко.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.0-34-59.000.jpg|frame|right|Как вы сводите к минимуму конфликты слияний?]]
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | {{question}} Одна из характеристик централизованных систем — это то, что именно
| + | |
| − | тот разработчик, который должен коммитить, обязан также
| + | |
| − | провести слияние. Как с этим в <tt>git</tt>?
| + | |
| − | И как вы сводите к минимуму конфликты слияний?
| + | |
| − | | + | |
| − | '''Линус''':
| + | |
| − | | + | |
| − | Спасибо, что спросили меня об этом!
| + | |
| − | Это не вас ли я просил задать этот вопрос?
| + | |
| − | | + | |
| − | Одно из самых приятных свойств <tt>git</tt> это то, что он реально проще
| + | |
| − | разбирается со слиянием, чем все остальные системы.
| + | |
| − | Объединение ветвей в CVS происходит крайне мучительно, просто невыносимо.
| + | |
| − | | + | |
| − | По моим подсчетам ядро Линукса — это на самом деле один из крупнейших
| + | |
| − | проектов с открытыми исходниками.
| + | |
| − | У нас <tt>22 000</tt> файлов.
| + | |
| − | | + | |
| − | Мы используем <tt>git</tt> уже два года.
| + | |
| − | В течение этих двух лет у нас было в среднем <tt>4.5</tt> слияния в день!
| + | |
| − | | + | |
| − | Если бы слияние было бы сложным, то точно пользовались чем-то другим.
| + | |
| − | Так что <tt>git</tt> делает слияния простыми.
| + | |
| − | | + | |
| − | Но у вас неизбежно возникнут разборки между какими-нибудь двумя программистами,
| + | |
| − | из тех, кто шлет мне просьбы «пожалуйста, возьми мой код»,
| + | |
| − | а я беру первый попавшийся вариант, просто потому что его заявка оказалась
| + | |
| − | раньше в моем почтовом ящике.
| + | |
| − | | + | |
| − | А другой чел поменял код так сильно и его версия настолько конфликтует с остальными
| + | |
| − | (такое бывает, правда не очень часто),
| + | |
| − | что я говорю: «Я мог бы это пофиксить, но мне лень».
| + | |
| − | В их области я не программирую — это не моя сфера интересов,
| + | |
| − | это сетевые технологии или что-то в этом духе,
| + | |
| − | я просто не могу разобраться и оценить этот код, не могу его тестировать,
| + | |
| − | так что просить меня разобраться с этим слиянием — просто глупо,
| + | |
| − | так дела не делаются.
| + | |
| − | | + | |
| − | Ага, комп с Виндой опять погас.
| + | |
| − | | + | |
| − | Итак, помните, что распределенная модель означает, что «особенных» нет.
| + | |
| − | | + | |
| − | Поэтому вместо того чтобы самому разбираться со слиянием,
| + | |
| − | я вытаскиваю первое дерево файлов, в котором не было никаких проблем,
| + | |
| − | и говорю второму участнику:
| + | |
| − | «Эй, я пробовал подгрузить твой код, но там была туча конфликтов со слиянием,
| + | |
| − | совсем не тривиальных, так что я решил, что тебе стоит разобраться с этим самому».
| + | |
| − | | + | |
| − | И они разбираются.
| + | |
| − | Они знают, что делать, потому что это их изменения.
| + | |
| − | | + | |
| − | Итак, они объединяют изменения и, вероятно, считают меня дебилом,
| + | |
| − | потому что слияние для них так просто и очевидно,
| + | |
| − | что я должен был принять их код с самого начала.
| + | |
| − | | + | |
| − | Зато они сами объединяют изменения, обновляют свое дерево файлов и говорят мне:
| + | |
| − | «Эй, теперь можешь забирать рабочий вариант», и я загружаю себе их версию.
| + | |
| − | Они прекрасно сделали всю работу за меня.
| + | |
| − | | + | |
| − | В этом-то и есть вся прелесть: ''они все сделали за меня''.
| + | |
| − | А мне достаются честь и хвала!
| + | |
| − | Далее мне просто нужно подсчитать третью составляющую — ''PROFIT!!!''
| + | |
| − | | + | |
| − | Все это аспект, естественным образом возникающий в распределенных системах,
| + | |
| − | это не особенность <tt>git</tt>. Да, <tt>git</tt> справляется со слияниями гораздо проще, чем все остальные,
| + | |
| − | но это свойство вытекает из самой распределенной модели.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.0-38-02.885.jpg |frame|right|…зачем вам так нужно иметь эту распределенную систему?]]
| + | |
| − | | + | |
| − | '''Зритель''':
| + | |
| − | | + | |
| − | {{question}} Слушай, я не совсем понимаю, зачем вам так нужно
| + | |
| − | иметь эту распределенную систему…
| + | |
| − | Ну да, вроде получаешь кучу преимуществ, по крайней мере
| + | |
| − | для коммерческой разработки, да и для разработки open-source наверно очень полезно,
| + | |
| − | поскольку каждый может работать сам по себе,
| + | |
| − | но, когда у тебя централизованная СУВ, общая структура директорий и файлов,
| + | |
| − | не окажется ли, что централизованная система с дешевыми ветками
| + | |
| − | даст тот же самый эффект?
| + | |
| − | Или такое просто невозможно?
| + | |
| − | | + | |
| − | | + | |
| − | '''Линус''':
| + | |
| − | | + | |
| − | Я готов поспорить, что централизованные системы не могут работать нормально,
| + | |
| − | но если у вас корпоративная среда с жестким контролем, то, действительно,
| + | |
| − | централизованные системы работают лучше,
| + | |
| − | и, безусловно, правда в том, что люди используют централизованные системы
| + | |
| − | в течение последних 35 лет.
| + | |
| − | И никто не будет спорить с тем, что централизованные системы не могут работать.
| + | |
| − | | + | |
| − | Они не могут работать так же хорошо, как и распределенные системы!
| + | |
| − | | + | |
| − | Одна из проблем состоит в том, что у централизованных систем неизбежны проблемы
| + | |
| − | при совместной работе групп из разных мест.
| + | |
| − | | + | |
| − | Как правило, они отлично работают если у вас лежит толстенное оптоволокно,
| + | |
| − | и я думаю, что у Гугла наверняка есть своя достойная внутренняя сеть,
| + | |
| − | так что эта проблема для вас, в отличие от остальных, не настолько критична,
| + | |
| − | но, поверьте мне, когда вам не нужно лезть в сеть за каждым файлом,
| + | |
| − | это существенно улучшает производительность.
| + | |
| − | | + | |
| − | Эээ… мда, я не могу показать вам демонстрацию,
| + | |
| − | да и не так уж она интересна,
| + | |
| − | но это ноутбук 4-5-летней давности.
| + | |
| − | Что-то типа ''Pentium-M 1.6 GHz''.
| + | |
| − | | + | |
| − | Я мог бы показать вам, что полный <tt>diff</tt> проекта Linux Kernel
| + | |
| − | на этом ноуте займет чуть больше секунды.
| + | |
| − | | + | |
| − | На моей основной машине, это уже будет меньше десятой доли секунды.
| + | |
| − | | + | |
| − | Это прирост производительности, которого вы никогда не добьетесь,
| + | |
| − | работая по сети.
| + | |
| − | | + | |
| − | Как только вы стали использовать сеть, хоть для пары пакетов,
| + | |
| − | вы уже впустую потратили производительность.
| + | |
| − | | + | |
| − | Так что если у вас децентрализованная система, и вы привыкли
| + | |
| − | делать <tt>commit</tt> или <tt>diff</tt> всего дерева исходников за 30 секунд,
| + | |
| − | то, может быть, 30 секунд вам не покажутся злом.
| + | |
| − | | + | |
| − | Но поверьте, когда вы привыкли делать это за одну десятую секунды,
| + | |
| − | 30 секунд — это полный отстой.
| + | |
| − | | + | |
| − | Так что, даже если вас супер сеть, всегда есть проблемы с производительностью.
| + | |
| − | Не говоря уж о том, что у большинства и в помине нету хорошей сети.
| + | |
| − | | + | |
| − | Другая заморочка — это ветки. Даже если вы
| + | |
| − | очень эффективно реализовали ветвления, сам факт того, что вы создаете
| + | |
| − | ветки и каждый может их увидеть, потому что все централизовано, означает,
| + | |
| − | что волей-неволей вам не захочется делать никаких веток.
| + | |
| − | | + | |
| − | У вас будут проблемы с пространством имен.
| + | |
| − | | + | |
| − | Как вы назовете свою ветку?
| + | |
| − | Вы назовете ее «test»?
| + | |
| − | Ага-ага, уже есть 5000 других веток,
| + | |
| − | названных «test1», «test2», … «test5000», так что вам теперь придется
| + | |
| − | выдумывать новые правила именования
| + | |
| − | ваших веток, потому что у вас централизованная система
| + | |
| − | с централизованным пространством имен у ветвей,
| + | |
| − | что совершенно неизбежно при работе с централизованной системой.
| + | |
| − | | + | |
| − | Как же это работает в распределенной среде разработки?
| + | |
| − | | + | |
| − | Вы называете свою ветку «test», и все!
| + | |
| − | Ну на самом деле, вам не следовало бы ее так называть, веткам нужно давать имена
| + | |
| − | согласно их функциональности; называйте их кратко, благозвучно
| + | |
| − | и конкретно — что эта ветвь делает.
| + | |
| − | | + | |
| − | Git дает вам по умолчанию одну ветку под названием «master»:
| + | |
| − | красиво, коротко и ясно — это ваш основной ствол.
| + | |
| − | | + | |
| − | Но вы можете создать ветку под названием
| + | |
| − | «experimental-feature-x» — и все будет понятно.
| + | |
| − | | + | |
| − | Но в централизованной среде вы просто не сможете так сделать.
| + | |
| − | Вы не можете назвать ветку «experimental-feature-x».
| + | |
| − | Вы должны придумывать тупые, идиотские названия.
| + | |
| − | | + | |
| − | Я работал в компании, у которой были прекрасные скрипты для CVS,
| + | |
| − | настолько прекрасные, насколько это возможно, они помогали создавать ветки.
| + | |
| − | Вы даже могли создать ветку с помощью одной простой команды,
| + | |
| − | это не занимало много времени — система фиксировала имя вашей ветки,
| + | |
| − | добавляя к ней число.
| + | |
| − | Вы определяете базовое имя, говоря:
| + | |
| − | «это моя ветка, она делает то-то и то-то», и система называет
| + | |
| − | вашу ветвь: «то-то-и-то-то—56».
| + | |
| − | | + | |
| − | И система добавит тег/закладку там, где вы начали разрабатывать эту ветку,
| + | |
| − | потому что в CVS вам приходится это делать…
| + | |
| − | Это занимало некоторое время, но работало.
| + | |
| − | | + | |
| − | Вы можете так извращаться в централизованных системах, но вам не нужно этого делать!
| + | |
| − | | + | |
| − | Ваша система децентрализована, она просто работает.
| + | |
| − | | + | |
| − | Именно так все и должно работать.
| + | |
| − | | + | |
| − | Итак, я ничего не утверждаю, я не собираюсь вас убеждать переходить
| + | |
| − | на децентрализованную систему,
| + | |
| − | я просто констатирую факт: «Вы тупые дебилы»!
| + | |
| − | | + | |
| − | Таков расклад.
| + | |
| − | | + | |
| − | Как бы то ни было, перейдем к слайду «Performance».
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.0-43-15.833.jpg|frame|right|…сколько файлов осилит <tt>git</tt>?]]
| + | |
| − | | + | |
| − | | + | |
| − | '''Зритель''':
| + | |
| − | | + | |
| − | {{question}} Могу я задать вопрос?
| + | |
| − | | + | |
| − | '''Линус''':
| + | |
| − | | + | |
| − | Давай.
| + | |
| − | | + | |
| − | '''Зритель''':
| + | |
| − | | + | |
| − | {{question}} На самом деле, два вопроса.
| + | |
| − | Первый: сколько файлов осилит <tt>git</tt>?
| + | |
| − | а второй, представьте, что у вас здоровенная древовидная структура файлов в <tt>git</tt>,
| + | |
| − | возможно ли извлечь только часть этой структуры?
| + | |
| − | | + | |
| − | '''Линус''':
| + | |
| − | | + | |
| − | Отличные вопросы.
| + | |
| − | | + | |
| − | На самом деле, эти вопросы цепляют совсем другую тему,
| + | |
| − | хотя они связаны с производительностью.
| + | |
| − | | + | |
| − | Одно из особенных свойств <tt>git</tt> — отслеживание изменений всего содержимого,
| + | |
| − | и это отличает <tt>git</tt> даже от [[EnPedia:Mercurial_(software)|Mercurial]], несмотря на то, что они очень похожи.
| + | |
| − | | + | |
| − | Он никогда не отслеживает отдельный файл.
| + | |
| − | Вы не можете прослеживать изменения файла в <tt>git</tt>.
| + | |
| − | | + | |
| − | Ну, вы можете проследить изменения проекта, в котором один единственный файл.
| + | |
| − | Если в вашем проекте один файл, то у вас все получится,
| + | |
| − | но если вы отслеживаете изменения в десяти тысячах файлов, то <tt>git</tt> никогда не будет
| + | |
| − | возиться с ними по отдельности.
| + | |
| − |
| + | |
| − | Git думает, что все вокруг — это единый проект.
| + | |
| − | Вся история в <tt>git</tt> основана на истории проекта целиком.
| + | |
| − | | + | |
| − | Отсюда — важные следствия для производительности.
| + | |
| − | | + | |
| − | Когда вы используете CVS, вполне нормально, хотя и глупо,
| + | |
| − | иметь один здоровенный репозиторий с миллионом файлов внутри.
| + | |
| − | | + | |
| − | Таким образом, в конце дня, поскольку CVS думает о каждом
| + | |
| − | из миллиона файлов по отдельности,
| + | |
| − | вы можете попросить CVS обновить только один единственный файл —
| + | |
| − | все это в рамках CVS-идеологии.
| + | |
| − | И это верно для множества других моментов.
| + | |
| − | | + | |
| − | Точно также работает и BitKeeper, и это является одной из его ошибок.
| + | |
| − | | + | |
| − | Проблема мышления в «концепции наблюдения за каждым файлом по отдельности»
| + | |
| − | возникает очень часто, особенно, если вы разработчик высокого уровня (как я).
| + | |
| − | У меня 22 тысячи файлов, и мне пофигу, что происходит с одним из них.
| + | |
| − | Возможно, я буду следить за подмножеством из тысячи файлов,
| + | |
| − | например, коллекцией файлов по подсистеме USB.
| + | |
| − | Но я никогда не беспокоюсь о каком-то отдельном файле.
| + | |
| − | | + | |
| − | Поэтому <tt>git</tt> следит за всем, как за коллекцией файлов,
| + | |
| − | и если вы попросите историю конкретного файла,
| + | |
| − | <tt>git</tt> буквально начнет с глобальной истории и упростит ее.
| + | |
| − | Это очень эффективная система, вам даже в голову не придет что это так,
| + | |
| − | но в действительности, когда вы пытаетесь следить за миллионом файлов
| + | |
| − | в репозитории, а потом просите историю конкретного файла — это очень тормозит систему.
| + | |
| − | Таким образом, свойства масштабирования у <tt>git</tt> сильно отличаются от других систем,
| + | |
| − | благодаря этой фундаментальной особенности.
| + | |
| − | | + | |
| − | Мы работали с большими репозиториями.
| + | |
| − | Мы импортировали историю проекта KDE из SVN, может быть, не всего,
| + | |
| − | но уж <m>\frac34</m> точно.
| + | |
| − | И KDEнутые … эээ… ''Я не должен так их называть… Я не буду, поверьте, мне нравится KDE.''
| + | |
| − | | + | |
| − | Но они засунули все компоненты в один репозиторий!
| + | |
| − | Не слишком умно.
| + | |
| − | Получилось так, что тот репозиторий, который, думаю, весил 8 Гб под CVS,
| + | |
| − | в SVN разбух еще в три раза!
| + | |
| − | Ну может там было меньше 8 Гб под CVS, но он был действительно огромным.
| + | |
| − | Точно больше 4 Гб.
| + | |
| − | Git же сжал это безобразие до где-то 1.3 Гб.
| + | |
| − | | + | |
| − | Итак, <tt>git</tt> очень эффективен в обработке этого проекта,
| + | |
| − | почти все работает отлично, но не все и не всегда.
| + | |
| − | | + | |
| − | Система не заработает хорошо, если вы поместите миллион файлов
| + | |
| − | в один репозиторий при начальном клонировании.
| + | |
| − | Когда вы его запрашиваете, вы получаете его целиком.
| + | |
| − | Вы сваливаете все в один репозиторий, <tt>git</tt> думает, что это один обьект.
| + | |
| − | Не делайте так.
| + | |
| − | | + | |
| − | Если у вас есть множество компонентов, размещайте их в отдельные репозитории,
| + | |
| − | вы можете даже создать суперпроект, в котором содержатся указатели
| + | |
| − | на другие проекты, при этом что-то теряется в пользовательском интерфейсе,
| + | |
| − | но вы храните разные проекты по отдельности.
| + | |
| − | Тогда вы избежите проблемы «получения всего сразу».
| + | |
| − | Потому что с <tt>git</tt> вам придется получить все и сразу.
| + | |
| − | | + | |
| − | '''Из зала''':
| + | |
| − | {{question}} Как насчет разделяемого кода?
| + | |
| − | | + | |
| − | '''Линус''':
| + | |
| − | | + | |
| − | Если они все «расшарили» свой код, что вы можете сделать с помощью <tt>git</tt>,
| + | |
| − | если у вас действительно много «расшаренных» файлов,
| + | |
| − | то поскольку <tt>git</tt> внутри использует «файловую систему идентифицируемую содержимым»,
| + | |
| − | то если существуют одинаковые по содержанию файлы,
| + | |
| − | <tt>git</tt> будет использовать для них в точности один и тот же объект.
| + | |
| − | И сохранит вам тонны свободного места.
| + | |
| − | | + | |
| − | И у вас могут быть эти расшаренные объекты, и в тоже время
| + | |
| − | они могут храниться у вас как отдельные сущности.
| + | |
| − | Вы также можете хранить их в раздельных репозиториях,
| + | |
| − | но лежащих на одной разделяемой файловой системе.
| + | |
| − | Вы можете это сделать!
| + | |
| − |
| + | |
| − | Если у вас действительно есть расшаренный код, ну например,
| + | |
| − | библиотека, которая используется в пяти разных местах,
| + | |
| − | то если вам стоить использовать поддержку супер-проекта, где у вас есть
| + | |
| − | один репозиторий <tt>git</tt>, который просто отслеживает остальные репозитории <tt>git</tt>,
| + | |
| − | (и он тоже может содержать например, разделяемую инфраструктуру сборки),
| + | |
| − | но при этом индивидуальные части остаются индивидуальными.
| + | |
| − |
| + | |
| − | Это похоже на модули CVS.
| + | |
| − | В CVS модули не до конца индивидуальны, но это потому,
| + | |
| − | что в CVS каталог — это вещь, которая всегда сама по себе,
| + | |
| − | так что модуль CVS — это комбинация «каталожности» и их отслеживания,
| + | |
| − | но в целом вы можете думать об этом как о модулях CVS.
| + | |
| − | | + | |
| − | В общем, мы поддерживаем такую возможность, но вынужден согласиться,
| + | |
| − | что код довольно сырой, и это единственная область, где
| + | |
| − | наши пользовательские интерфейсы определенно отстают.
| + | |
| − | | + | |
| − | Возможно, я забыл ответить на какую-то часть вашего вопроса.
| + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.0-49-34.467.jpg|frame|right|Можно ли извлечь из репозитория только часть файлов?]]
| + | |
| − | | + | |
| − | '''Из зала:'''
| + | |
| − | | + | |
| − | {{question}} Можно ли извлечь из репозитория только часть файлов, а не целый репозиторий?
| + | |
| − | | + | |
| − | '''Линус:'''
| + | |
| − | | + | |
| − | Вы можете экспортировать тарболы или отдельные файлы,
| + | |
| − | вы можете переписать всю историю, сказав
| + | |
| − | «Я хочу новую версию этого репозитория, которая содержит только эту часть»,
| + | |
| − | вы можете это сделать, это довольно дорогая операция,
| + | |
| − | это что-то типа, импорта старого репозиторий в новый огромный репозиторий,
| + | |
| − | который потом делиться на меньшие части.
| + | |
| − | Вы можете это сделать, но я подчеркиваю, что следует этого избегать.
| + | |
| − | | + | |
| − | Неверно, что <tt>git</tt> не может обрабатывать большие проекты,
| + | |
| − | просто производительность будет не так хороша,
| + | |
| − | а вы будете иметь проблемы, которых можно было бы избежать.
| + | |
| − | | + | |
| − | Так что я пропускаю этот вопрос и возвращаюсь к теме производительности.
| + | |
| − | | + | |
| − | == Performance ==
| + | |
| − | | + | |
| − | Одна из вещей, которую я хочу сказать по поводу производительности,
| + | |
| − | это то, что, похоже, огромное количество людей, кажется, думают, что
| + | |
| − | производительность это «как делать то же самое, но быстрее»,
| + | |
| − | а это неправда.
| + | |
| − | | + | |
| − | ''[показывает слайд «Производительность».]''
| + | |
| − | [[Image:Linus-git-googletalk.0-51-10.996.jpg|right]]
| + | |
| − | | + | |
| − | Производительность — в первую очередь не это.
| + | |
| − | | + | |
| − | Если вы можете делать что-то действительно быстро,
| + | |
| − | действительно хорошо, люди начнут использовать это по-другому.
| + | |
| − | | + | |
| − | Одна из вещей, в которой я хочу вас убедить — это
| + | |
| − | то, что слияния происходят очень-очень быстро, потому что
| + | |
| − | я хочу, чтобы люди сливали как можно раньше и чаще,
| + | |
| − | потому что тогда это легче делать.
| + | |
| − | Если вы объединяете изменения каждый день, вы никогда не попадете
| + | |
| − | в неожиданную ситуацию с тяжелыми трудноразрешимыми конфликтами.
| + | |
| − | | + | |
| − | Итак, если вы действительно легко делаете ветвление и слияние,
| + | |
| − | вы избегаете целого класса проблем, которые в противном случае
| + | |
| − | требуют много-много времени, чтобы их избежать.
| + | |
| − | | + | |
| − | Например, давайте вернемся к одной из вещей, где,
| + | |
| − | как мне кажется, разработчики Subversion показали себя полными идиотами.
| + | |
| − | | + | |
| − | Жестко сказано, правда?
| + | |
| − | | + | |
| − | Наверняка несколько из них сейчас в этой комнате.
| + | |
| − | | + | |
| − | Ну вы и тупые!
| + | |
| − | | + | |
| − | ''[смех]''
| + | |
| − | | + | |
| − | Например, Subversion очень шумно хвалится, что
| + | |
| − | они исправили CVS, сделав ветвления дешевыми.
| + | |
| − | Это есть на их главной странице, где они вроде говорят,
| + | |
| − | что ветвление в SVN требует ''O(1)'' операций,
| + | |
| − | и что можно сделать дешевых ветвей столько, сколько хотите.
| + | |
| − | | + | |
| − | Неважно, что ''O(1)'', мне кажется, на самом деле имеет
| + | |
| − | довольно большое ''O'', но даже если ветвление занимает микросекунду,
| + | |
| − | кого это волнует?
| + | |
| − | | + | |
| − | Вы меряете не то, что нужно.
| + | |
| − | | + | |
| − | Ветки полностью бесполезны, если Вы не объединяете их,
| + | |
| − | а CVS не может объединить вообще ничего.
| + | |
| − | Вы можете слить изменения однажды,
| + | |
| − | но тогда CVS забывает то, что вы сделали, и вы никогда не
| + | |
| − | сможете объединять снова, не получая адские конфликты.
| + | |
| − | Слияния в Subversion — полная беда.
| + | |
| − | Разработчики Subversion отчасти признают это, и у них есть некий замысел,
| + | |
| − | но эти идеи тоже фигня.
| + | |
| − | | + | |
| − | Невероятно, насколько эти люди глупы.
| + | |
| − | Они все время смотрели на проблему неверно.
| + | |
| − | Проблема-то не в ветвлении, а в слиянии!
| + | |
| − | А нормальное слияние они так за пять лет и не сделали.
| + | |
| − | Вот что грустно.
| + | |
| − | | + | |
| − | Итак, быстродействие важно, но надо смотреть в корень проблемы.
| + | |
| − | | + | |
| − | Затраты на то, чтобы сделать ветку под <tt>git</tt>,
| + | |
| − | буквально заключаются в создании 41-байтного файла.
| + | |
| − | Ну насколько это быстро, как думаете?
| + | |
| − | Не думаю, что вы даже сможете это измерить.
| + | |
| − | Вы можете, в общем, если вы используете Windows, вероятно
| + | |
| − | вы можете измерить это, потому что… [''аудитория: смех'']
| + | |
| − | но как бы то ни было, это так быстро, что реально вы
| + | |
| − | не сможете это измерить.
| + | |
| − | И это создает ветку.
| + | |
| − | Но никого это не волнует, это-то не проблема.
| + | |
| − | | + | |
| − | Единственное, что важно, это как быстро вы можете сливать изменения.
| + | |
| − | В <tt>git</tt> вы можете объединить… я сливаю изменения в 22 тысячах файлов несколько раз в день, и я недоволен,
| + | |
| − | если объединение занимает более пяти секунд,
| + | |
| − | и все эти пять секунд загружаются в основном уходят на загрузку ''diffs'', ладно, не ''diffs'',
| + | |
| − | а дельты между двумя деревьями, а само объединение занимает менее
| + | |
| − | чем полсекунды.
| + | |
| − | | + | |
| − | И я не должен думать об этом.
| + | |
| − | | + | |
| − | Вот что длится дольше чем слияние, это то, что после каждого слияния,
| + | |
| − | по умолчанию <tt>git</tt> сделает <tt>diffstat</tt>
| + | |
| − | всего, что изменилось в результате объединения, потому что
| + | |
| − | мне это важно.
| + | |
| − | Когда я вливаю чьи-то изменения, я им доверяю, но с другой стороны,
| + | |
| − | вдруг они уже забросили свои лекарства?
| + | |
| − | Так что я доверяю им, да, но будем говорить начистоту — может
| + | |
| − | они были в порядке вчера, но сегодня был не их день…
| + | |
| − | Так что для контроля я делаю <tt>diffstat</tt> и <tt>git</tt> тоже делает <tt>diffstat</tt> по умолчанию,
| + | |
| − | хотя вы конечно можете для скорости его отключить, но лучше не надо,
| + | |
| − | <tt>diffstat</tt> по-любому быстр, и обычно занимает…, ну если большое слияние,
| + | |
| − | обычно занимает секунду-другую.
| + | |
| − | Поскольку создание ''diff'' и фактически подсчет статистики о том, сколько
| + | |
| − | строк изменилось — намного более затратная операция,
| + | |
| − | чем выполнение непосредственно слияния.
| + | |
| − | | + | |
| − | Это вид быстродействия, который фактически изменяет ваш стиль работы.
| + | |
| − | Это не улучшения быстродействия тех же действий, а возможность работать
| + | |
| − | совершенно по-другому.
| + | |
| − | Вот что на самом деле означает производительность, и вот почему
| + | |
| − | вам не стоить смотреть ни на что, кроме <tt>git</tt>.
| + | |
| − | | + | |
| − | Hg (Mercurial) довольно хорош, но <tt>git</tt> лучше.
| + | |
| − | | + | |
| − | Я думаю, что у меня заканчивается время, мы посмотрим, есть ли еще …,
| + | |
| − | … о, ОК это все еще интересно.
| + | |
| − | | + | |
| − | Мы еще не добрались до части про реализацию,
| + | |
| − | но не беспокойтесь, я сейчас я много об этом расскажу:
| + | |
| − | реализация очень проста.
| + | |
| − | | + | |
| − | Код и структуры данных очень-очень-очень просты.
| + | |
| − | Если вы посмотрите на исходный текст и поймете,
| + | |
| − | что там всего где-то 80000 строк, в основном на Cи,
| + | |
| − | ну на таком Си, на котором пишу я — большинство его не понимает,
| + | |
| − | но зато я комментирую код.
| + | |
| − | | + | |
| − | Исходный код может порой выглядеть сложным,
| + | |
| − | потому что мы очень печемся о производительности, особенно я.
| + | |
| − | Я действительно забочусь об этом, и иногда заставляю вещи работать сильно быстрее,
| + | |
| − | но при этом приходится использовать более сложные алгоритмы,
| + | |
| − | чем последовательная проверка файлов по очереди.
| + | |
| − | Когда вы делаете слияние 22 тысяч файлов, вы не хотите проверять по одному файлу,
| + | |
| − | вы хотите посмотреть все дерево сразу и сказать:
| + | |
| − | «А они же одинаковые, я не должен ничего делать».
| + | |
| − | В общем, <tt>git</tt> делает все такие штуки, и все это несколько раздувает объем кода,
| + | |
| − | ибо по-уму все это сделать непросто, но основы все же очень и очень просты.
| + | |
| − | | + | |
| − | И одна из этих основ, это аспект безопасности и надежности.
| + | |
| − | | + | |
| − | ''Показывает слайд:''
| + | |
| − | [[Image:linus-git-googletalk.0-56-39.330.jpg|center]]
| + | |
| − | | + | |
| − | Когда <tt>git</tt> отслеживает ваш проект, мы сжимаем каждый блок данных,
| + | |
| − | вычисляя дельту (различия) по отношению ко всем другим блокам,
| + | |
| − | кроме того мы вычисляем SHA-1 хеш, который проверяется при
| + | |
| − | необходимости достать этот блок.
| + | |
| − | | + | |
| − | Если у вас побился диск или память, или что-то еще в этом роде — <tt>git</tt> об этом сообщит.
| + | |
| − | Это даже не вопрос. Это безусловная и безоговорочная гарантия.
| + | |
| − | | + | |
| − | У вас могут быть люди, пытающиеся навредить.
| + | |
| − | У них не выйдет.
| + | |
| − | | + | |
| − | Вам нужно точно знать 20 байтов 160-битного SHA-1 хеша от верхушки вашего дерева,
| + | |
| − | и если вы их знаете, вы сможете доверять вашему дереву сверху донизу,
| + | |
| − | всей истории целиком.
| + | |
| − | У вас может быть десять лет истории проекта с сотней тысяч файлов,
| + | |
| − | миллионами ревизий, но вы сможете доверять любой части любой ревизии.
| + | |
| − | Потому что <tt>git</tt> такой надежный, и все его основные структуры данных
| + | |
| − | очень-очень просты.
| + | |
| − | | + | |
| − | Да, мы проверяем контрольные суммы.
| + | |
| − | Но мы не считаем ''слабую'' контрольную сумму, как у некоторых UDP пакетов,
| + | |
| − | то есть 16-битную сумму всех байтов.
| + | |
| − | Мы проверяем контрольные суммы, которые считаются криптографически стойкими.
| + | |
| − | | + | |
| − | Никто не может взломать SHA-1, но дело в том, что для <tt>git</tt>,
| + | |
| − | SHA-1 это не функционал информационной безопасности,
| + | |
| − | а просто проверка целостности.
| + | |
| − | Безопасность там отдельно.
| + | |
| − | | + | |
| − | А то полно народу думают, что раз <tt>git</tt> использует SHA-1,
| + | |
| − | а SHA-1 используется во всяком криптографическом софте,
| + | |
| − | то наверно это крутая фича в безопасности.
| + | |
| − | Так вот, ничего тут нет общего с безопасностью,
| + | |
| − | это просто самый лучший хеш из имеющихся.
| + | |
| − | | + | |
| − | Хороший хеш дает гарантию целостности данных, а также
| + | |
| − | кучу других возможностей, например, то, что когда мы хешируем обьекты,
| + | |
| − | мы знаем, что получившийся хеш будет иметь добротное, годное распределение,
| + | |
| − | и нам не нужно беспокоится о разных проблемах с ним.
| + | |
| − | С точки зрения реализации, это означает, что мы считаем, что
| + | |
| − | хеш настолько хорош, что мы можем использовать этот алгоритм хеширования,
| + | |
| − | и считать, что у нас нет плохих случаев (коллизий).
| + | |
| − | | + | |
| − | Ну то есть, есть тут некоторые основания и с криптографической стороны,
| + | |
| − | но все это только про гарантии целостности ваших данных.
| + | |
| − | Я вам гарантирую, что если вы положите ваши данные в <tt>git</tt>,
| + | |
| − | спустя пять лет, даже если вы сконвертировали их с вашего
| + | |
| − | винчестера на какой нибудь DVD, или что там будет вместо него,
| + | |
| − | вы сможете проверить ваши данные и вернуть их назад в том же состоянии,
| + | |
| − | в котором вы поместили их в систему.
| + | |
| − | Именно этого вы и должны ждать от любой системы контроля версий.
| + | |
| − | | + | |
| − | Одна из причин, по которой я так агитирую за это, состоит в том,
| + | |
| − | что у нас был случай со взломом одного из сайтов BitKeeper’а,
| + | |
| − | когда народ пытался испортить репозиторий с исходниками ядра,
| + | |
| − | а BitKeeper отловил эту попытку.
| + | |
| − | Но BitKeeper не имеет по настоящему крутого хеша,
| + | |
| − | думаю, там простейший 16-CRC код, или что-то типа этого.
| + | |
| − |
| + | |
| − | В принципе, это достаточно, чтобы заметить неуклюжую попытку подмены,
| + | |
| − | криптографически оно ненадежно, но на практике атаки сделать уже непросто,
| + | |
| − | так что тогда атака была немедленно пресечена.
| + | |
| − | | + | |
| − | Но после того, как такое случилось,
| + | |
| − | когда ты уже погорел на этом,
| + | |
| − | уже не хочется попасться в эту же ловушку снова.
| + | |
| − | | + | |
| − | Нет, ну может ваши проекты и не очень важные, но мои проекты точно важны, и поэтому
| + | |
| − | я об этом так пекусь.
| + | |
| − | | + | |
| − | Это — также одна из причин, … вернемся на секунду к концепции распределенности …,
| + | |
| − | ну, например, вы делаете ваш проект [[EnPedia:Google Code|Google code]],
| + | |
| − | где можно держать исходники в ваших репозитариях,
| + | |
| − | так вот — я бы никогда не доверил Google хранить и поддерживать мои исходники.
| + | |
| − | Извините, но вы еще не заслужили моего доверия.
| + | |
| − | | + | |
| − | Причина, по которой я предпочитаю распределенные системы,
| + | |
| − | состоит в том, что я могу держать свой исходный текст позади
| + | |
| − | трех брандмауэров на системе, которая не позволяет даже по <tt>ssh</tt> войти.
| + | |
| − | Вот здесь я не могу читать свою электронную почту, потому что моя почта
| + | |
| − | идет на мою машину и единственный путь, как я могу попасть на мою машину
| + | |
| − | — это когда я физически нахожусь в той сети.
| + | |
| − | | + | |
| − | Может я конечно и полностью свихнулся, может только слегка сдвинулся,
| + | |
| − | и я забочусь о безопасности больше, чем большинство окружающих.
| + | |
| − | Да и вообще, чтобы я дал эталонную копию репозитария исходников,
| + | |
| − | о котором я так пекусь, куда-то на сторону?
| + | |
| − | Абсурд!
| + | |
| − |
| + | |
| − | Даже Гуглу не дам.
| + | |
| − | Никогда в жизни, хоть ты меня режь.
| + | |
| − | | + | |
| − | Я позволю Google держать копию репозитория, но
| + | |
| − | хочу чтобы было что-то, про что я знаю точно, что никто это не трогал.
| + | |
| − | | + | |
| − | Кстати, я не такой уж и крутой сисадмин, так что сбой на винте
| + | |
| − | для меня определенно будет проблемой, так как бэкапами я не заморачиваюсь.
| + | |
| − | Но все будет в порядке, если я смогу загрузить обратно данные из нескольких
| + | |
| − | доверенных источников. Я смогу их сравнить друг с другом, это реально просто,
| + | |
| − | я смогу сверить их хеши с теми самыми 20 байтами, о которых я очень-очень
| + | |
| − | заботился — надеюсь, в нескольких местах они останутся.
| + | |
| − | | + | |
| − | 20 байтов отследить легче, чем 180 МБ.
| + | |
| − | | + | |
| − | И очень маловероятно, что побьются именно эти 20 байтов.
| + | |
| − | | + | |
| − | И если у меня есть эти 20 байтов, я могу загрузить <tt>git</tt>-репозитрий даже
| + | |
| − | из совершенно «левого» источника, и могу гарантировать, что они не сделали с ним ничего плохого.
| + | |
| − | | + | |
| − | Ваш проект [Google Code] — хостинг репозитариев для народа — крутое и благое дело,
| + | |
| − | вот только вы неправильно делаете, если используете для него Subversion.
| + | |
| − | Из-за вас люди ночами спать спокойно не будут!
| + | |
| − | | + | |
| − | Конечно, если вы делаете это для 70 … , сколько там проектов,
| + | |
| − | 75 тысяч?
| + | |
| − | Большинство из них довольно мелкие и ерундовые, так что все в порядке.
| + | |
| − | Но если бы вы все сделали правильно, люди бы чувствовали себя получше.
| + | |
| − | | + | |
| − | У меня есть еще несколько слайдов,
| + | |
| − | Но я думаю, что мы уже превысили лимит времени,
| + | |
| − | и не хотелось бы грузить вас их показом,
| + | |
| − | я думаю, они не очень интересны.
| + | |
| − | | + | |
| − | == Content Management ==
| + | |
| − | | + | |
| − | Я уже немного говорил на тему «Полный целостный проект vs. Отдельные файлы»,
| + | |
| − | и что <tt>git</tt> отслеживает именно полный проект.
| + | |
| − | | + | |
| − | [[Изображение:linus-git-googletalk.1-03-18.642.jpg|framed|right| «Это гораздо больше чем случайный набор файлов»]]
| + | |
| − | | + | |
| − | Ну тут на слайде единственный пример с вызовом из командной строки,
| + | |
| − | ''gitk'' — это GUI вьювер истории проекта под <tt>git</tt>,
| + | |
| − | это скрипт на tcl/tk для просмотра всей той информации, которую <tt>git</tt>
| + | |
| − | действительно хорошо показывает, а вот это пример командной строки, которую я использую как
| + | |
| − | «мейнтейнер» высшего уровня.
| + | |
| − | | + | |
| − | Я хочу просто спросить «что изменилось с некоторой версии», или быть может «некоторой даты».
| + | |
| − | Я могу легко выяснить, что поменялось «в этих двух каталогах» или
| + | |
| − | «в этих двух каталогах и этом файле»,
| + | |
| − | и мне будет показана полная история, относящаяся к этой части репозитория.
| + | |
| − | | + | |
| − | Это более затратно, чем просто посчитать полную историю всего проекта.
| + | |
| − | Если бы мой ноутбук был подключен сейчас к видеовыходу,
| + | |
| − | я бы показал, что все это происходит за считанные секунды,
| + | |
| − | то есть дороговато, но в целом ничего.
| + | |
| − | | + | |
| − | Этот функционал <tt>git</tt> по-настоящему уникален!
| + | |
| − | Больше никто этого не может, а эта функциональность очень важна!
| + | |
| − | Может быть, она и не так важна для отдельного разработчика,
| + | |
| − | потому что отдельный разработчик часто думает в терминах отдельных файлов,
| + | |
| − | но важно для людей, объединяющих версии проекта.
| + | |
| − | Это важно для таких как я и тех, с кем я непосредственно работаю,
| + | |
| − | потому что они практически никогда не заботятся об отдельных файлах,
| + | |
| − | а вот такие вещи для них важны.
| + | |
| − | Кто-нибудь отправляет отчеты об ошибке, которые не всегда адекватны,
| + | |
| − | но пусть вам попался довольно вменяемый отчет,
| + | |
| − | и вы можете сразу засечь — «Ага, это подсистема SCSI».
| + | |
| − | | + | |
| − | Вот командная строка (''указывает на слайд'').
| + | |
| − | | + | |
| − | Вы не можете указать точно проблемный файл, но можете сказать:
| + | |
| − | «Удали последние 15 тысяч коммитов, сделанных с прошлой недели, и он откатит
| + | |
| − | проект до 50 [коммитов]»
| + | |
| − | | + | |
| − | Это круто, и никакая другая система так не может, уверяю.
| + | |
| − | | + | |
| − | Вот поэтому вы и должны хотеть использовать именно <tt>git</tt>.
| + | |
| − | Вот к чему это сводится.
| + | |
| − | Он надежен и так безопасен, что вы можете делать то, что
| + | |
| − | остальные системы или не делают, или делают очень медленно,
| + | |
| − | и кроме того, он распределенный.
| + | |
| − | | + | |
| − | Итак, продолжим.
| + | |
| − | Полагаю, мы можем позволить ответить на еще один вопрос.
| + | |
| − | Что у нас с временем, я как-то без понятия… Ладно, давайте быстро.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:linus-git-googletalk.1-05-57.109.jpg|framed|right|…будет просто дрейф проблем с масштабируемостью…?]]
| + | |
| − | | + | |
| − | '''''Слушатель:'''''
| + | |
| − | | + | |
| − | {{question}} Итак, причина ухода с Perforce — на самом деле масштабируемость и эффективность.
| + | |
| − | Иначе люди просто продолжат ее использовать.
| + | |
| − | И может, при переходе будет просто дрейф проблем с масштабируемостью и производительностью
| + | |
| − | из одной области в другую?
| + | |
| − | | + | |
| − | '''''Линус:'''''
| + | |
| − | | + | |
| − | Ну я уже говорил, что я без понятия, как вы работаете
| + | |
| − | с Perforce, и какие с ним проблемы, но если вы перейдете на <tt>git</tt>,
| + | |
| − | вы можете быть в нем уверены, если, конечно,
| + | |
| − | вы будете использовать его в разумных пределах.
| + | |
| − | А эти пределы обычно достаточно очевидны.
| + | |
| − | У вас есть компилятор, основные исходники,
| + | |
| − | документация, ну может ваша документация разбросана как-то фрагментами,
| + | |
| − | хотя наверняка у вас есть что-то типа пользовательской документации,
| + | |
| − | может в Google не так, но во многих компаниях отдельно
| + | |
| − | идет набор документации для потребителей
| + | |
| − | и документации, сопровождающей отдельные модули и пакеты.
| + | |
| − | | + | |
| − | Так что одним из моментов использования <tt>git</tt>, о котором стоит подумать,
| + | |
| − | это как организовать разумную структуру проекта.
| + | |
| − | Git легко поддерживает здоровые проекты, вы можете без проблем держать в нем
| + | |
| − | десятки тысяч файлов, вот в Ядре, например, их 22 тысячи.
| + | |
| − | Мы тестировали на ста тысячах — и все было в порядке — <tt>git</tt> быстрей, чем что бы то ни было.
| + | |
| − | | + | |
| − | С миллионом файлов, подозреваю, другие системы, могут быть в чем-то и побыстрее.
| + | |
| − | И не хотелось бы, чтобы вы попали в такую ситуацию.
| + | |
| − | Но если вы правильно организуете проект и грамотно настроите,
| + | |
| − | <tt>git</tt> будет и быстрее и лучше, что все остальное.
| + | |
| − | Я уверен в его исключительной производительности.
| + | |
| − | | + | |
| − | Вот одна из вещей, которую мы не очень хорошо делаем,
| + | |
| − | это «CVS annotate»<ref>Команда, сообщающая по каждой строчке автора, совершившего в этой строчке последнее изменение и последнюю ревизию, в которой эта строчка менялась.</ref>.
| + | |
| − | Люди часто используют эту команду.
| + | |
| − | Я говорил, что у Perforce оно тормозит, так что вы,
| + | |
| − | вероятно, хотя и не уверен, не используете Perforc’ный «annotate».
| + | |
| − | Но пользователи CVS используют «CVS annotate»,
| + | |
| − | эту единственную операцию, которую CVS может выполнять быстрее, чем <tt>git</tt>,
| + | |
| − | потому что CVS работает «пофайлово», а <tt>git</tt> — нет.
| + | |
| − | | + | |
| − | У <tt>git</tt> есть «annotate», но фактически это будет поиск,
| + | |
| − | вы можете узнать об этом, если вы переместите функцию из одного файла в другой,
| + | |
| − | <tt>git</tt> дословно воспроизведет историю функции, даже несмотря на перемещение.
| + | |
| − | Внимание, не перемещение файла, а функцию в пределах файла
| + | |
| − | он пойдет и откопает и скажет:
| + | |
| − | «Эй! Эти две строки на самом деле пришли из
| + | |
| − | того файла 5 лет назад».
| + | |
| − | | + | |
| − | Опять-таки, это оригинальный функционал, который больше никто не тянет,
| + | |
| − | и сводится он к тому же, что рулит контент проекта целиком, а не файлы по отдельности.
| + | |
| − | Но за это приходится платить, так что если вы отматываете лет на пять назад,
| + | |
| − | это может занять секунд 30.
| + | |
| − | На ядре это занимает секунду для любого имеющегося у меня файла,
| + | |
| − | ведь два года назад мы начали историю с чистого листа, решив
| + | |
| − | «давайте не будем усложнять то, что не требуется»,
| + | |
| − | — и прямо сейчас у нас имеется только двухлетняя история ядра.
| + | |
| − | | + | |
| − | В других проектах у нас есть история и подлинней,
| + | |
| − | мы делали на них замеры, например, после импорта KDE и других проектов
| + | |
| − | с еще более длинной историей.
| + | |
| − | Тут бывают проблемы с производительностью, но все равно даже
| + | |
| − | с учетом таких проблем <tt>git</tt> на один-два порядка быстрее, так что
| + | |
| − | в основном беспокоиться не о чем.
| + | |
| − | | + | |
| − | И если обнаружите какую-нибудь проблему, то у нас сейчас очень-очень
| + | |
| − | классное сообщество.
| + | |
| − | В <tt>git</tt>-овом списке email-рассылок уровень «шума» очень мал,
| + | |
| − | и хотя писем там изрядное количество, это очень вменяемый мейллист.
| + | |
| − | Итак, если кто-то заинтересовался, посмотрите исходники,
| + | |
| − | но начните с просмотра архива рассылки.
| + | |
| − | У нас есть и свои флеймы, есть и бесцельные споры,
| + | |
| − | но большинство сообщений там весьма хороши.
| + | |
| − | | + | |
| − | OK? Спасибо…
| + | |
| − | | + | |
| − | [''апплодисменты'']
| + | |
| − | | + | |
| − | == Ссылки ==
| + | |
| − | <references/>
| + | |
| − | | + | |
| − | {{replicate-from-custiswiki-to-lib}}
| + | |
