Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Сначала я кратко расскажу про системы контроля версий для тех, кто о них ничего не знает или знает мало, а потом пару слов скажу про выступление Линуса Торвальдса, в котором он рассказывает о Git'е.
Зачем вообще нужен какой-то контроль за кодом? Затем, что без контроля получается бардак. На диске появляются бесконечные копии исходников с загадочными именами: MyProject1, MyProject.backup, MyProject.old, MyProject.oldest. Проку в них никакого нет, потому что все равно уже не вспомнить где какие изменения делались.
Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями. Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.
Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.
Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает :-).
Транк (trunk) - основная ветка кода
Бранч (branch) - ответвления (для экспериментов, например)
Чекин (Check in (submit, commit)) - отправка кода в репозиторий
Чекаут (Check out) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом
Updated 20.07.2008 Вообще терминология расходится, всё зависит от того, о какой именно системе идет речь. Например, "check out" в Perforce имеет несколько иное значение.
Традиционная схема работы с репозиторием в Open Source проектах такова. Есть некто Главный (пусть будет Ведущий программист, неважно). Программисты делают патчи, цепляют их к багам в багтракинговой системе. Главный просматривает их патчи, если все ОК - применяет к коду. В Second Life используется схема работы с патчами. В качестве багтракинговой системы там используется JIRA, в качестве системы контроля версий - Subversion.
В компаниях такая схема тоже иногда применяется, при работе со стажерами. Чтобы кто-то просматривал их код, прежде чем он попадет в репозиторий. Обычные же программисты, как правило, имеют право коммита.
Вот выступление Линуса Торвальдса, в котором он рассказывает про им написанную систему контроля версий Git. Тон рассказа мне не очень понравился, Линус там периодически пытается несмешно шутить по поводу своей популярности. Кстати, по ходу доклада гугловцы упоминают, что у них используется Perforce.
Линус не любит Perforce, не любит CVS, не любит Subversion. Он ратует за распределенные системы контроля версий. Которые, мало того, что убирают точку отказа, но еще делают более простым процесс создания бранчей и позволяют смело экспериментировать с кодом, не вызывая комплексов "засабмитить не то".
Я думаю, Git получит рапространение хотя бы по тому, что его написал Линус. Еще пример использования распределенной системы контроля версий - Bazaar используется при работе над Ubuntu Linux.
Большой список систем контроля версий можно посмотреть в Википедии.
Ссылки по теме:
Boost переехал в Subversion репозиторий
Updated 23.09.2007
M. Sf. в комментариях подробно рассказывает о своем опыте работы с Git'ом
Updated 05.01.2008
Девять причин перейти на Git
Quaternions and spherical trigonometry
3 дня назад
Atom feed
44 коммент.:
Посмотрите ещё в сторону Darcs. Он не очень фичастый и плохо подходит для работы 10000 человек, но зато чрезвычайно простой и удобный.
Линус на Git, Ubuntu на Bazaar, Mozilla на Mercurial... Скоро все будем на распределенных системах сидеть и SubVersion вспоминать с такой же ностальгией как сейчас CVS.
А у нас - TFS и Vault. Рулят!
Посмотрите ещё в сторону Darcs
...
А у нас - TFS и Vault. Рулят!
Вообще интересно, да, чем люди пользуются.
О словарике: в словарик я бы еще добавил термин "мёрдж" (слияние кода из различных веток), так как без него ни транк, ни бранч сами по себе смысла особого не имеют.
Насчет Git - думаю, время покажет. Линус или не Линус, но если это будет неудобно в использовании - сообщество единогласно освистает не взирая на фамилии :)
ЗЫ. У нас используется ClearCase.
Я думаю, что для домашнего удовольствия можно использовать что-то наподобие subsersion, что я собственно и делаю.
А для групповых разработок - конечно нужно использовать распределённые системы. Я использую mercurail.
CVS живее всех живых. А атомарные мультикоммиты отлично эмулируются внешней обвязкой вроде cvstrac.
Perforce редкостное гавно, даже хуже чем SourceSafe. Удивительно что некоторые люди платят за этот комерческий кал деньги когда есть бесплатные SVN или на худой конец CVS. Я сейчас помогаю одной софтверной компании и они используют Perforce, это что-то, друзья мои. Народ тратит больше времени на коммиты, корявые попытки развести брэнчи и т.п. чем на реальную работу.
Исторически сложилось, что часть проектов сидит в CVS, а часть в SVN, мы в SVN, причем слезли на него с Visual Source Safe до сих пор вспоминаю с ужасом :)
Правильное название "Subversion", не "SubVersion" :)
По поводу Perforce - поддерживаю. всмысле неодобряю... Не понимаю как можно тратить деньги на такое по.
Распределенные системы контроля - это очень удобно. Лично у меня уже выработалась привычка коммитить, а тут новый проект - новые правила - коммитим только значимые изменения, чтобы логи не засорять... :( неправильно это...
По поводу используемых систем - из распределенных ИМХО очень хорош monotone, о котором Линус Торвальд, кстати упоминал, в пору ухода с БитКипера, для тех, кто предлагал перевести ядро на Subversion.
А для себя я сейчас юзаю тот же Subversion, с распределенным фронтендом svk.
Дрон.
Алена, я бы тоже согласился, что использование git - вопрос религии (сам использую Subversion). Но, по этому вопросу, помниться, уже был спор (ссылку не приведу, потерялась). Факт тот, что размер репозитария git и репозитария svn для крупных проектов отличается на порядок. Для ядра это очень критично.
Существенный недостаток git - некросплатформенность, т.е. под "единой ОС" его запустить будет проблематично, ибо официального порта нету.
По поводу PerForce - оно бесплатное для двух разработчиков, если мне память не изменяет.
Мы долго использовали SourceSafe. Имхо, вполне нормально. Потом перешли на MS Team Server.
Да, замечательная презентация.
70 минут и 14 секунд. Из них минимум минут 30 потрачено для декларации (именно декларации, а не доказательства) тезиса, что CVS - говно.
Ну во-первых он прав. CVS - говно. А Ford-T 1929 года выпуска что тогда? Говно или нет? По крайней мере, он ездит хуже, чем Ford-Focus 2007. Но именно он сделал революцию и ушёл в историю. Поймите же, что сегодня CVS-а нет, точно так же, как нет Ford-T. Есть SVN.
Итак, по главному тезису возражений нет. Что дальше?
На метке 35.12 начался разговор по делу. И уупс, выяснилось, что в GIT тоже есть merges. Какая неприятность... Правда они "гораздо безболезней, потому что ..." Потому что, что? А хрен его знает... Видимо потому, что Линус ими не занимается, оставляя на совести разработчиков договорится друг с другом, если конфликтов слишком много. Ну и? А в SVN я, конечно, сам бы делал мерджи, не информируя разработчиков :-) ...
С чем действительно спорить невозможно - это то, что децентрализованые системы сильно лучше централизованых, если у вас хреновая сеть. Или надо много работать без доступа к сети. 100%. Абсолютно правильно. Вот только где в современной корпоративной среде он хреновую сеть найдёт???
---
Теперь по пунктам, которые он упомянул.
Global branches namespace - Да, есть такое дело. Ну поставь username разработчика в качестве префикса имени и забудь. Тоже мне big deal.
Individual files (content management) - исправлено в SVN
Performance - исправлено в SVN
If you merdge every day, you never get to point where you have huge conflicts you need to resolve. - Выгравировать золотом на платиновой табличке и повесить на стенку. Да. Вот только мы говорим о правилах работы, и, казалось бы, причём здесь Карфаген, то есть CVS :-) ?
Merging history - Да, это дейсвительно вещь интересная и стоящая, которой в SVN нет.
Checksums, security, etc - То же самое (для тех, кому это реально нужно, а нужно далеко не всем).
---
Что в сухом остатке? Грубо говоря - возьми SVN, делай на каждый чих свой брэнч, мерджи их каждый день - вот тебе и GIT. Конечно это не так, это преувеличение, но всё же...
Да, у GIT есть преимущества. Причём, в большей части это касается методологии работы, а не собственно технической реализации системы. Хотя я верю, что реализация там тоже блестящая, всё-таки не абы кто писал :-)
И наконец, Линус как координатор гигантского проекта совершенно упускает из виду проекты на 10-20 человек, которые зачастую сидят в одной комнате. А таких проектов (или наборов таких проектов) тоже немало. И там все эти преимущества исчезают...
Merging history - в subversion 1.5 будет merge tracking, правда подробностей не изучил
Да, и в дополнение - не упомянуть GNU arch было просто нечестно, поскольку git должен сравниваться именно с arch-ом, как системы одного класса...
Лично я предпочитаю TortoiseSVN (http://ru.wikipedia.org/wiki/TortoiseSVN). Жаль только, что ее нельзя интегрировать в Far...
А вообще, использовать системы контроля версий если разработчик всего один, считаю бессмысленным (при условии, что проект не сильно огромных размеров). Причем особенно это заметно если проект постоянно меняется - добавляются и удаляются файлы с кодом, часть кода полностью переписывается... В этом случае старое-доброе копирование папки с проектом оказывается все-таки эффективнее, т.к. лезть и смотреть "как там было сделано месяц назад" при сильно меняющемся коде просто бессмысленно - слишком велики изменения. В этой ситации как правило требуется просто поднять часть старого кода чтобы сделать Copy&Paste маленького его кусочка
Все это естественно - имхо. Может у меня стиль кодирования такой :) Неправильный...
2rsx11:
Линус, конечно, некрасиво понаезжал на CVS и не только на CVS, но все же ты местами не прав.
И уупс, выяснилось, что в GIT тоже есть merges. Какая неприятность... Правда они "гораздо безболезней, потому что ..." Потому что, что? А хрен его знает...
Он там рассказывает, например, про такой момент: GIT лучше помнит историю изменений и напомнит про функцию даже если она со временем уехала далеко по строкам файла. Или даже если уехала в другой файл.
А у нас CVS. И никаких особых проблем не наблюдается.
Алёна, я тоже впечатлился этим примером (про функцию уехавшую в другой файл). Видимо это и есть следствие merge tracking. Ну и ещё распределённая архитектура. И это всё :-(.
>Лично я предпочитаю TortoiseSVN. Жаль только, что ее нельзя интегрировать в Far...
Для far-а есть плагины, прикручивающие контекстное меню эксплорера (EMENU) и правый клик мышкой (RightClick) для вызова этого самого emenu, так что никаких проблем.
у нас на работе для централизованной разработки - Subversion, а вот для своих проектов я использую меркуриал - распределенные системы контроля версий очень удобны, особенно, когда часто мотаешься с нотебуком без постоянного доступа к центральному репозиторию. Еще одна вещь за которую я их люблю - дешевые бранчи - если мне надо поэксперементировать с новыми фичами, я не забиваю центральный сервер своими промежуточными версиями - все хранится у меня, и я выкатываю уже обкатанный код.
git - это конечно хорошо, но он непереносим на non-unix платформы, так что mercurial был логичным выбором (можно еще посмотреть на bzr, он тоже на питоне написан).
У меня была идея написать статью про распределенные системы контроля версий, но она так и умерла практически в зародыше. Правда у меня есть статья про использование Emacs для работы со всем этим зоопарком :-)
2 sergey_:
я имел много проблем с CVS при хранении в нем XML документации - постоянно на пустом месте показывал конфликты и т.п. ну и большая проблема (для меня) - неатомарные коммиты, когда невозможно откатить сделанные изменения пачкой
2 fahrain:
даже для одного разработчика, система контроля версий должна быть. Например, у тебя образуется две версии продукта - стабильная и эксперементальная, в стабильной ты фиксишь баги, в эксперементальной - делаешь новые вещи. Но одни и те же баги надо фиксить в обоих версиях, менять вручную в обоих версиях? зачем - есть merge, которые и отследит чтобы все слилось более-менее правильно, да и запомнит что такое слияние уже было.
to Alex Ott:
>Например, у тебя образуется две версии продукта - стабильная и эксперементальная
Пока что у меня как-то так получается, что стабильных версий нет :) Кроме того, последний год я стремлюсь все проекты делать из слабосвязанных модулей (или статически или динамически подгружаемых .dll). В этом случае создание экспериментальной версии сводится к простой замене одного из модулей.
И, опять таки, самое главное - системы контроля версии имеет смысл использовать только при достижении проектом некоторого критического объема кода или же если разработчиков - несколько.
Вот на данный момент мой основной проект - ertranslator.googlepages.com - содержит примерно 41 тыс. строчек кода. Но фактически он состоит из кучи малосвязанных модулей, каждый из которых состоит не более чем из 1500 строк кода (суммарно по модулю).
Фактически, сейчас я могу абсолютно безболезненно проводить абсолютно любые эксперименты :)
Я не призываю забить на системы контроля версий :) Просто можно построить проект так, что их применение не дает никаких преимуществ...
И, опять таки, самое главное - системы контроля версии имеет смысл использовать только при достижении проектом некоторого критического объема кода или же если разработчиков - несколько.
Не согласен с тобой. По достижению этого критического объёма уже может сложиться плачевная ситуация в виде десятка-другого папок-бэкапов и иже с ними.
Лучше использовать SCM с первых строк проекта. Это как минимум удобно.
Для сравнения можно противопоставить раскиданные по всему компьютеру(или по нескольким компьютерам) текстовые файлы со всякими заметками против чего-нибудь централизованного аля google notebook, outlook, и им подобным решениям.
2Alex Ott
Приветствую, Alex, как обычно очень интересный комментарий.
git - это конечно хорошо, но он непереносим на non-unix платформы
Именно непереносим, в принципе? А почему?
У меня была идея написать статью про распределенные системы контроля версий, но она так и умерла практически в зародыше.
Жаль, было бы интересно почитать.
Git is targeted to run on Linux, but can be used on other Unix-like operating systems including BSD, Solaris and Darwin. Git is extremely fast on POSIX-based systems such as Linux.
Officially git runs on Windows, but this requires the installation and use of Cygwin (a POSIX emulation). Git on Windows is noticeably slower,[44] due to git's heavy use of file system features that are particularly fast on Linux.[45] In addition, many people find Cygwin installation too large and invasive for typical Windows use.
http://en.wikipedia.org/wiki/Git_%28software%29#Portability
------GIT--------
Git устроен как файл-система с логами т.е. историей
Идея Гит'а в том, что:
(а) есть файлы
(б) есть их хранение в "индексе"-кэше. Там файлы получают имена совпадающие с криптографической SHA-1 - это означает, что Гит-система следит за содержимым файла, а не только за его именем. Любые изменения в файле будут распознаваться Гит'ом
Попав в индекс-кэш файлы не просто начинают храниться как "объекты" в нем, но для них пишется и индекс быстрого доступа.
(в) Когда нужно сделать "точку истории" в развитии проекта, она пишется командой git-commit. Т.е. содержимое индекс-кэша записывается как некий "commit object", со своим SHA-1, и если нужно, с криптографической подписью разработчика.
(г) ТАКИМ ОБРАЗОМ, все операции в Гит'е происходят между файлами и индекс-кэшем, между индекс-кэшем и "историческими объектами".
Для сокращения этой логики есть также и wrapper scripts и команды, которые делают промежуточную стадию незаметной для пользователя (т.е. взять файлы из дерева и сразу их commit в "исторический объект").
Ну и к этому - команды для получения информации - листингов файлов, какие изменились, какие отправ;ены в индекс, какие нет; как файлы из индекса или из рабочей директории сравниваются с историческими.
Чтение любых из этих объектов и сравнение их друг с другом.
Получение diff-ов, которые тут же превращаются в patch-и. Упаковка их для раздачи.
Плюс - как разводить и сводить ветви в "истории", branching and merging.
(д) Гит - полностью распределенная система. Поэтому в нем на основе libcurl сделана возможность экономного обмена друг с другом - с приемом в основное дерево или отдельную ветвь (которую можно сравнивать с вашими старыми, сливать и т.д.).
Распределенность в том, что вы можете играть с проектом сами, никому не мешая - нет центрального места ни диктатора, ни нужды делать свою работу публично. Сделав, вы предлагаете другим взять разницу от вас и посмотреть.
Таким образом, Гит в чем-то -- a generic piece of software. Он как выполняемая вручную файлсистема с логом и историей, со сжатием и крипто-слежением за файлами. На его основе можно писать программы p2p или программы слежения за работой ваших серверов (как monitors, так и административные поддержки конфигураций)
Недостаток его в том, что писали его компьютерные ботаники, а потому команд много (больше 70) - хотя нужных меньше - и они разные: часть вписана в сам головной файл git, часть - скрипты-обертки вокруг него.
Поэтому для упорядочения бардака люди сделали несколько "porcelains", т.е. оберток, которые резко снижают число управляющих команд, например, cogito.
Я придерживаюсь мнения, что самым эффективным средством упорядочивания является собственный вкус - а потому держу файл с aliases, который делит команды на 4 простых группы:
- "gind" для операций между рабочими файлами и индекс-кэшем
- "gobj" между индекс-кэшем и "историей объектов"
- "gdiro" между историей и рабочими файлами не упоминая стадии индекса
- и "ginfo" для опроса Гит'а о разного рода информации.
В каждой из трех первых групп aliases часто повторяют друг друга:
например, gind.ls даст листинг файлов, как его видит индекс-кэш, gobj.ls - как он отражен в committed версиях и т.д.
При работе в юниксе aliases дополняются оболочкой (shell), а потому их не надо печатать до конца.
Набираешь gi, хлопаешь на "таб" и получаешь "gind.", хлопаешь на таб 2 раза - и получаешь список всех возможных команд ("gind.ls gind.ls,status gind.co gind.ls,help и т.д.).
Если надо узнать что скрывается под кличкой, в юниксе печатают "type gind.ls" и система объясняет, какая "взаправдашняя" команда стоит за ней.
Вот такая логика, идеи по использованию и такие у меня свои незамедляющие Гит "porcelains".
Я его стал использовать для _сжатого_ (т.е. compressed) хранения любой важной информации на моих юниксах - например, конфигураций, которые я могу легко пересылать на административную машину, следить за всеми изменениями, восстанавливать версии и т.д.
А кроме SubVersion что порекомендуете?Дело в том,что там,чтобы проинсталлировать пакет,надо регистрироваться.Создавать аккаунт только ради того,чтобы посмотреть/поиграться как-то не очень хочется...
Спасибо.
2nvy:
А кроме SubVersion что порекомендуете?Дело в том,что там,чтобы проинсталлировать пакет,надо регистрироваться.
CVS можно попробовать. Я, правда, не знаю как там с регистрацией.
Он устарел, но поиграться его хватит.
Спасибо за быстрый и точный ответ.
P.S.Отвечать на данный комент не надо
используем ClearCase, потому как в Motorola Mobile Devices это традиционный способ :-) Распределенная работа над большим кодом удобна. а нас только небольшая часть исходников - база с терабайтик :-)
Понятно кто когда что менял, зачем
http://youtube.com/watch?v=8dhZ9BXQgc4
Нашёл раcсказ Рэндела Шварца о Git.
Добавил в русскую WiKi. Заодно хотел бы сообщить вам.
Довольно интересно и познавательно.
2Borisov Sergey
Нашёл раcсказ Рэндела Шварца о Git.
Добавил в русскую WiKi. Заодно хотел бы сообщить вам.
Довольно интересно и познавательно.
Действительно очень хороший доклад, спасибо.
2 M.Sf.
>>Я придерживаюсь мнения, что самым эффективным средством упорядочивания является собственный вкус - а потому держу файл с aliases, который делит команды на 4 простых группы:
>>- "gind" для операций между рабочими файлами и индекс-кэшем
>>- "gobj" между индекс-кэшем и "историей объектов"
>>- "gdiro" между историей и рабочими файлами не упоминая стадии индекса
>>- и "ginfo" для опроса Гит'а о разного рода информации.
С удовольствием позаимствовал бы ваш опыт, а можно посмотреть какие команды у вас привязаны на эти алиасы?
А вот я сейчас всех поражу своим комментом!
Кто-нибудь сможет что-нибудь подсказать для контроля версий готового продукта? Ситуация такова:
1. Есть законченный Продукт (грубо говоря - программа со всем комплексом хелпов, экзешников, длллек и конфигурационников)
2. Периодически выпускаются новые версии продукта, которые необходимо тестировать
3. На стабильных версиях (существуют несколько типов комплектации) периодически выпускаются обновления (длл+конфиги)
4. Необходимо обеспечить контроль версий - чтобы изменения со стабильных версий попадали и в многочисленные тестовые версии в разные типы сборок.
Уже реально задолбало всё делать вручную - править конфиги для многочисленных тестовых версий после малейшего чиха в стабильной и т.д.
Есть какие-нить соображения по этому поводу?
2Borizzz:А вот я сейчас всех поражу своим комментом!
Не поразил. :-) Такая же фигня была. Плакали, мучались, правили всё руками. Решения так и не нашли.
Максим комментировал...
Существенный недостаток git - НЕКРОСплатформенность,
Баюс! Баюс! :-)
Тут RSS лента есть?
2Анонимный:
Тут RSS лента есть?
Да
http://alenacpp.blogspot.com/atom.xml
Помогите разобраться.
Я электронщик. Никогда не пользовался этими системами. Но часто бывает, что сам рисуеш схему, сам делаеш разводку и пишеш программу. Таким образом проект состоит из разнообразных файлов. Можно ли с помощью вышеперечисленных средств вести контроль за версиями? И если можно, то подтолкните в сторону "как".
Анонимный
Помогите разобраться.
Я электронщик. Никогда не пользовался этими системами. Но часто бывает, что сам рисуеш схему, сам делаеш разводку и пишеш программу. Таким образом проект состоит из разнообразных файлов. Можно ли с помощью вышеперечисленных средств вести контроль за версиями? И если можно, то подтолкните в сторону "как".
В систему контроля версий можно положить любой файл. То есть в каком бы виде вы ни хранили схемы, их можно туда класть, потом по мере необходимости обновлять, но при этом уметь доставать и поздние версии, если это нужно.
Попробуйте Tortoise SVN, у него приятный интерфейс. Попробовав, вы поймете, подходит вам это или нет.
кратко непонятно хреново
могла бы чего подоступнее написать
Отправить комментарий