Персональные инструменты
 

Линус Торвальдс о GIT на Google Talk — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м (1 версия)
м (#REDIRECT)
 
(не показаны 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}}
+

Текущая версия на 01:19, 18 февраля 2010

Перенаправление на: