Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 125
Уговорил!
Спасибо большое. Читал в оригинале, но мой английский оставляет желать лучшего…
Интереснее былобы посмтреть на сравнени с git. Я сам Mercurial не пользовался ниразу, но догадывался что он схож с git. А то что git в разы удобнее чем subversion я в принципе познал на практике.
По мне так это вопрос привычки, хотя конечно отличия есть, вот кое что по теме proft.com.ua/2010/10/17/spravochnik-po-git-i-mercurial/
Почитал материал по ссылке, за что большое спасибо. В принципе, как подметил мой товарищ, единственное преимущество, которое он заметил это то, что в «hg» буковок меньше чем «git» )
Субъективно лично мне кажется hg как-то быстрее работает, хотя это возможно потому что с git работал лишь в windows с прослойкой cygwin, да и было это несколько лет назад.
git работает в разы быстрее, т.к. не на скриптовом языке написан
Вот вам батнички:
test-git.bat
test-hg.bat
Берем проектик на пару сотен файлов, выполняем батнички несколько раз…
Сразу становится видно, что hg в полтора-два раза медленнее git
test-git.bat
@echo %TIME%
@git init
@git add .
@git commit -q -m initial
@echo %TIME%
test-hg.bat
@echo %TIME%
@hg init
@hg add -q
@hg commit -q -m initial
@echo %TIME%
Берем проектик на пару сотен файлов, выполняем батнички несколько раз…
Сразу становится видно, что hg в полтора-два раза медленнее git
По-вашему commit к повседневной работе отношения не имеет?
Мощно, ладно еще понимаю push… Но commit, я лично десятки раз в день делаю…
Вы никогда не задумывались, какой смысл было разрабатывать git, когда есть hg?
Такой же опен-сорсный и распределенный?
Мощно, ладно еще понимаю push… Но commit, я лично десятки раз в день делаю…
Вы никогда не задумывались, какой смысл было разрабатывать git, когда есть hg?
Такой же опен-сорсный и распределенный?
pull в разы быстрее работает в hg, чем в git, по моим наблюдениям
> Вы никогда не задумывались, какой смысл было разрабатывать git, когда есть hg?
Такой же опен-сорсный и распределенный?
Возможно потому, что они появились одновременно, с разницей чуть меньше двух недель?
Такой же опен-сорсный и распределенный?
Возможно потому, что они появились одновременно, с разницей чуть меньше двух недель?
Похоже хабраэффект. У меня не открывается.
Они на столько схожи, что с помощью плагинов вы можете свободно работать из hg в git и наоборот. При этом иметь все плюшки друг-друга(лукавлю, почти все)
Тор Норби в одном из последних подкастов делился своим опытом перехода с HG (когда он был в Оракл) на Git (теперь он работает в Гугле). Считает киллер-фичей Гита возможность склеить несколько патчей в один коммит. Например, работаете вы над каким-то таском, добились какого-то рабочего состояния и решили выложить изменения. А потом оказалось, что код грязноват, мб где-то идет отклонение от style-guides или какие-то debug выводы остались. Все прочистили, сделали красиво и опять закоммитили. Так вот, в Git можно взять эти два чейнджсета и объединить в один — как будто код с самого начала писался чистенько и по стандартам. В результате, говорит он, все чейнджсеты оказываются по делу, что особенно важно в большом проекте, когда их в целом очень много.
Спасибо, этой особенности не знал. А фича действительно здоровская, надо будет почитать.
mq?
спасибо, интерсно!
в hg мне переодически приходится делать hg rollback и думать перед тем как запушить
в hg мне переодически приходится делать hg rollback и думать перед тем как запушить
Если вышеприведенные способы оказались «большими» и не изящными, можно попробовать расширение
mercurial.selenic.com/wiki/CollapseExtension, которое делает только и именно то, что вы описали.
mercurial.selenic.com/wiki/CollapseExtension, которое делает только и именно то, что вы описали.
аааа! Джоель, ты гениален! Что бы не пришлось изменять в команде, ты это уже попробовал и написал об этом статью.
Переводчику большой респект! Ждем продолжения.
Переводчику большой респект! Ждем продолжения.
Спасибо, заставили задуматься
Интересно, в чем отличие от git
Товарищ подсказал habrahabr.ru/blogs/development_tools/108443/#comment_3432920
кажется ссылка указывает на эту же страницу… или я не туда жму? :)
О! Проворонил :) Неприменно положу в закладки
Кстати, если кому интересно нашел вот это: www.ibm.com/developerworks/ru/library/l-vercon/
Слышал мнение, что git — он больше linux-way, а hg удобнее при разработке под виндой. Насколько правда — не знаю, мопед не мой.
Круть! Спасибо за перевод! С удовольствием прочитал бы оригинал! Последний обзац заставил меня попробовать Mercurial. В компании мы исспользуем SVN, но всегда хочеться попробовать что-то новенькое. Эта статья дала толчёк к новым изменениям!
Отличная статья. Я тоже потихоньку переползаю на DCVS вроде GIT. Но мне кажется, что все же некоторые страсти вроде
И почти в каждой команде мне сказали, что они поклялись «больше никогда» и отказались от веток. И теперь они делают так: каждая новая фича в большом #ifdef блоке.притянуты за уши. Что может быть хуже ifdef для новых фич в проектах? :)
Эх… А мне ведь осталось совсем маленько, чтобы перевод закончить. Спасибо, что сэкономили моё время :)
Кстати, сегодня как раз смотрел лекцию Торвальдса с переводом, где он рассказывает про свой Git (есть топик на Хабре). Идеи у него практически те же, что и у разработчиков Меркуриала. И он довольно неплохо обосновывает, что децентрализация гораздо лучше.
Кстати, сегодня как раз смотрел лекцию Торвальдса с переводом, где он рассказывает про свой Git (есть топик на Хабре). Идеи у него практически те же, что и у разработчиков Меркуриала. И он довольно неплохо обосновывает, что децентрализация гораздо лучше.
Упрёки к svn актуальны к древним версиям. В 1.6 уже более-менее приличные ветки. Единственное что меня не устраивает в svn это подключение к интернету для создания ветки.
Чем hg лучше git'а?
Mercurial действительно хорош и довольно прост в использовании. Когда переходили на него, тоже поначалу работали как с SVN, но потом образумились :)
Написано ясно и понятно, я сам только Clear Case и SVN использовал, много нового для себя открыл
много воды и рекламы меркурал.
На самом деле таким способом Джоел рекламирует свой Килн www.fogcreek.com/kiln/
ну, Ъ-мужики сразу бы прочитали весь mercurial wiki и сказали своё суровое «одобряю»
все лучше чем размусоливание темы.РФ и нытье про сотовых операторов…
А что будет в меркуриал, если я изменил что-то в коде функции, а мой коллега удалил её и внёс изменения в центральный репозиторий первым? Функция исчезнет? И как оповещается локальные ветки об изменениях в центральном репозитории? В ручную, через пул чэньджсет?
вас известят, я полагаю, и попросят сделать pull. Если ваши изменения имеют более позднюю версию то произойдет мерж (соответственно функция вернется все будет ок). Если нет то вам предложат сделать stash после чего вы обновите локальную версию и сможите закоммитить изменения которые вы stashнули. Это не о меркуриал это о гит, но подозреваю, что механизм и там и там одинаковый.
ЗЫ: Уточню известят при попытке pull'a. А вообще я придерживаюсь концепции девелоперских бранчей.
Т.е. разбить изменения на не пересекающиюся множества? Один работает над одним, другой над другим функционалом? Меня как раз интересовал вопрос об одновременном редактировании документа. По Вашим словам если даже я сначала что-то изменил, а потом это удалили (не зная о моих изменениях) то всё восстановится?
Отвечу на последний вопрос. Вам предложат смержить две ветки. Во время этого процесса вы сможете сделать с кодом всё что вам нужно. Оставить другой код, оставить ваш с изменениями, удалить оба и т.п.
>>Т.е. разбить изменения на не пересекающиюся множества?
Да именно так, но это скорее некое рудиментарное мышление оставшееся от svn. Хотя в git оно вполне применимо, и удобно.
>>По Вашим словам если даже я сначала что-то изменил, а потом это удалили (не зная о моих изменениях) то всё восстановится?
Именно так, опять же говоря о git. Система даст потерять ваши изменения только в случае если вы их сознательно потрете. В случае если вы пересечетесь с другим разработчиком, то кроме как сделать stash вам ничего не останется (ну или радикально потереть локальную версию и сделать новый клон). Ну и естественно если иземенения, которые вы сделали, невалидны, out-of-date(список продолжить), на человеческои уровне, можно просто потереть свои изменения из stash. Как-то так. я не очень владею навыком что-то объяснять признаюсь, мне больше удается показывать все на рисунках. Но надеюсь вам это поможет )
Да именно так, но это скорее некое рудиментарное мышление оставшееся от svn. Хотя в git оно вполне применимо, и удобно.
>>По Вашим словам если даже я сначала что-то изменил, а потом это удалили (не зная о моих изменениях) то всё восстановится?
Именно так, опять же говоря о git. Система даст потерять ваши изменения только в случае если вы их сознательно потрете. В случае если вы пересечетесь с другим разработчиком, то кроме как сделать stash вам ничего не останется (ну или радикально потереть локальную версию и сделать новый клон). Ну и естественно если иземенения, которые вы сделали, невалидны, out-of-date(список продолжить), на человеческои уровне, можно просто потереть свои изменения из stash. Как-то так. я не очень владею навыком что-то объяснять признаюсь, мне больше удается показывать все на рисунках. Но надеюсь вам это поможет )
Да, спасибо. То есть от ручного мерджа мы никуда не уходим, просто он реже встречается. Но так ведь и в СВН можно разграничить задачи изменения функционала до непересекающихся множеств. Если честно, я предпологал, что чэньджсет это дельта в смысле ленивых вычислений, тогда в любой момент мы можем вычислить конечный вариант документа, применяя цепочку последовательных дельт к исходному файлу, а цепочка эта может пополнятся как с конца, так и изнутри, т.е. могут вносится изменения, которые с точки зрения центральной ветки (глобальный коммит) произошли позже, но с точки зрения локальной ветки (локальный коммит) они предшествуют некоторым изменениям уже внесённым в центральную ветку. Т.е. ход времени в локальных ветках синхронизируется по центральной ветке.
Тут поспорить не могу, в свн по возможностям в принципе не ограничен. Но дело в инструменте. Если в свн возможность удобного удачного мержа средствами самой системы очень ограничена, то тут сама система предлагает надежный и удобный механизм мержа, по сути механизм, stash это, то что вы описали только «с разрешения пользователя».
Позволю себе продемострировать, как это будет выглядеть в коммандах:
$ git commit #коммит в ваш репозиторий
$ git push #push в «главный» репозиторий который уже поменялся
$ git stash save#Копируем сделаные вами изменения
$ git pull
$ git stash list
Позволю себе продемострировать, как это будет выглядеть в коммандах:
$ git commit #коммит в ваш репозиторий
$ git push #push в «главный» репозиторий который уже поменялся
$ git stash save#Копируем сделаные вами изменения
$ git pull
$ git stash list
прошу прощения парсер съел «теги»
$ git commit #коммит в ваш репозиторий
$ git push #push в «главный» репозиторий который уже поменялся
//тут сообщение о том что репозиторий поменялся
$ git stash save#Копируем сделаные вами изменения
$ git pull
$ git stash list
//тут список ваших stash'ей
$ git stash apply [ stash_id ]
$ git push
$ git commit #коммит в ваш репозиторий
$ git push #push в «главный» репозиторий который уже поменялся
//тут сообщение о том что репозиторий поменялся
$ git stash save#Копируем сделаные вами изменения
$ git pull
$ git stash list
//тут список ваших stash'ей
$ git stash apply [ stash_id ]
$ git push
в Hg при попытке pull никаких извещений не будет. Конфликт изменений обнаружится во время мержа своего коммита в текущий бренч. Соответсвенно выскочит 3-way merger для решения конфликта, а там уже вы сами решаете, восстановить удаленную функцию или нет.
А если коммит уже произошел, а pull перед этим не был сделан?
в локальном репозитории коммит создаёт новую неименованную ветку, тоесть после pull, серия коммитов еще не отправленных на центральный репозиторий, будет выглядеть как отдельная ветка. Вашей задачей перед выполнением push смержить ветку своих коммитов в основную ветку центрального репозитория.
ну значит мне больше нравится git )
Механизм мне в любом случае показался маленько запутаным, и неочевидным, но это наверное всеже дело привычки )
А вот насчет вашего высказывания объясните пожалуйста о чем вы вели речь?
fetch это обыкновенная загрузка, без каких либо мержей и т.п., так сказать «тупо качаем файлики», то что обрисовал выше товарищ AdvanTiSS намного умнее этого действа.
А вот насчет вашего высказывания объясните пожалуйста о чем вы вели речь?
fetch это обыкновенная загрузка, без каких либо мержей и т.п., так сказать «тупо качаем файлики», то что обрисовал выше товарищ AdvanTiSS намного умнее этого действа.
чтобы не плодить ветки можно сделать hg pull --rebase
уже некоторое время пользуюсь bitbucket.org, это просто мегаудобно! для обновления продакш-сервера достаточно сделать hg pull && hg update и все! но для этого хостинг должен предоставлять ssh (если это не VPS)…
а всякую мишуру типа обновления, переиндексации и прочих телодвижений можно вешать на триггеры
а всякую мишуру типа обновления, переиндексации и прочих телодвижений можно вешать на триггеры
> Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше.
Или я пример неправильно понял, или одно из двух, но при попытке его воспроизвести ничего кроме предложения вручную поправить конфликт при мерже не наблюдаю.
Или я пример неправильно понял, или одно из двух, но при попытке его воспроизвести ничего кроме предложения вручную поправить конфликт при мерже не наблюдаю.
Последняя капля в пользу Hg. Спасибо за обзор и сравнение, отличная статья.
> Subversion, по сути, система контроля изменений для файлов, а в Mercurial контроль изменений применяется ко всему каталогу, включая все подкаталоги.
Это утверждение может создать ложное впечатление.
На самом деле, Mercurial — система контроля изменений «только для файлов», она не знает что такое каталоги. Поэтому, например, вы не сможете закоммитить пустой каталог (но если очень надо, можно создать в нём пустой файл, и закоммитить). Но, при этом, выполнение операции в подкаталогах будет выполняться будто бы мы делаем это из корневого каталога репозитория. Каталог .hg содержится только в корне репозитория.
В Subversion, напротив, каталоги (в том числе и пустые) прекрасно коммитятся. Операции в подкаталогах же производятся «локально», поэтому, например, закоммитив какой-либо подкаталог, вы получите разные ревизии для него, и для корневого, то есть репозиторий можно привести в некоторое «противоречивое» состояние когда разные каталоги имеют разные ревизии. Получается, грубо, что каждый каталог — это репозиторий. В каждом каталоге есть .svn (или _svn).
Это утверждение может создать ложное впечатление.
На самом деле, Mercurial — система контроля изменений «только для файлов», она не знает что такое каталоги. Поэтому, например, вы не сможете закоммитить пустой каталог (но если очень надо, можно создать в нём пустой файл, и закоммитить). Но, при этом, выполнение операции в подкаталогах будет выполняться будто бы мы делаем это из корневого каталога репозитория. Каталог .hg содержится только в корне репозитория.
В Subversion, напротив, каталоги (в том числе и пустые) прекрасно коммитятся. Операции в подкаталогах же производятся «локально», поэтому, например, закоммитив какой-либо подкаталог, вы получите разные ревизии для него, и для корневого, то есть репозиторий можно привести в некоторое «противоречивое» состояние когда разные каталоги имеют разные ревизии. Получается, грубо, что каждый каталог — это репозиторий. В каждом каталоге есть .svn (или _svn).
можно вопрос? в чем идеалогический смысл коммитить пустые каталоги? Вообще зачем они нужны в репозитории? Если вы собираетесь в них что-то положить, но этого пока нет, то для коммандной работы я думаю будет полезно например положить в них файлик с описание, а что же там должно лежать.
То что вы привели как аргумент, это уродливый брат веток в mercurial и git.
То что вы привели как аргумент, это уродливый брат веток в mercurial и git.
Лично мне вообще ни зачем не надо, и я придерживаюсь вашей же точки зрения, здесь это как пример доказывающий отношения Mercurial к каталогам.
И поясните, пожалуйста, последнее предложение, никак не соображу, к чему это вы.
Ну в целом плодить множество каталогов как «отдельные репозитории», это то что легло в основу бранчей. Только вот если «бранчеваться» в svn невыносимо неудобно, долго и последующие действия над нимим невозоможно качественно и быстро выполнить без сторонних программ, то в git и (как я сегодня узнал ;) ) в mercurial это делается легко и не принужденно. Ну собственно вот )
каталоги — это те же файлы, только содержимое у них не текст, а другие файлы.
В чем идеологический смысл коммитить одни файлы, но не коммитить другие?
Вспомните, для чего нужен .hgignore (.gitignore).
В чем идеологический смысл коммитить одни файлы, но не коммитить другие?
Вспомните, для чего нужен .hgignore (.gitignore).
Ну если учитывать что в git файлы смысловой нагрузки тоже не несут, все заложено в changeset то смысла в пустых файлах тоже нет ;) Стрельнуло пока писал ЗЫ, для бинарных файлов, понятие файла всеже имеет смысл, делать changeset для них маленько не возможно )
Насчет gitignore тут как бы их роль очевидна, но связи я не улавливаю объясните )
И маленькое лирическое отступление аля ЗЫ: Мне вообще нравится это пост, я сегодня немало интересного и новго узнал )
Насчет gitignore тут как бы их роль очевидна, но связи я не улавливаю объясните )
И маленькое лирическое отступление аля ЗЫ: Мне вообще нравится это пост, я сегодня немало интересного и новго узнал )
Цитата из чудо-книги «Mercurial: The Definitive Guide»:
Empty directories are rarely useful, and there are unintrusive workarounds that you can use to achieve an appropriate effect.
The developers of Mercurial thus felt that the complexity that would be required to manage empty directories was not
worth the limited benefit this feature would bring.
Элементарные примеры.
1.
У меня есть болванка сайта. Это фреймворк с php-классами, но без вёрстки, без картинок и без всего такого что создаётся под проект. При этом, в болванке есть готовая структура папок на будущее:
/template/
/template/images/
/template/images/icons/
/template/images/buttons/
/template/images/bg/
/template/css/
/template/js/
…
Я всего лишь хочу, что бы структура папок была под контролем. Без этого теряется смысл фреймворка т.к. фреймворк — это не только готовые библиотеки.
Но создавать пустые файлы в каждой директории это невероятно тупорылый костыль.
2.
У меня есть папка /logs/ и я добавляю её в репозиторий. Но, так как логи пишутся при каждом запуске скрипта, я делаю для этой папки «ignore *» — что бы не было конфликтов.
Я бы мог вообще не добавлять эту папку под контроль, но тогда остальные программисты её не получат. А если не будет пустой папки, то PHP будет сильно ругаться на fopen('logs/sql.log.txt', 'a+');
1.
У меня есть болванка сайта. Это фреймворк с php-классами, но без вёрстки, без картинок и без всего такого что создаётся под проект. При этом, в болванке есть готовая структура папок на будущее:
/template/
/template/images/
/template/images/icons/
/template/images/buttons/
/template/images/bg/
/template/css/
/template/js/
…
Я всего лишь хочу, что бы структура папок была под контролем. Без этого теряется смысл фреймворка т.к. фреймворк — это не только готовые библиотеки.
Но создавать пустые файлы в каждой директории это невероятно тупорылый костыль.
2.
У меня есть папка /logs/ и я добавляю её в репозиторий. Но, так как логи пишутся при каждом запуске скрипта, я делаю для этой папки «ignore *» — что бы не было конфликтов.
Я бы мог вообще не добавлять эту папку под контроль, но тогда остальные программисты её не получат. А если не будет пустой папки, то PHP будет сильно ругаться на fopen('logs/sql.log.txt', 'a+');
гм а не проще создать один файлик вот с таким содержанием:
/template/
/template/images/
/template/images/icons/
/template/images/buttons/
/template/images/bg/
/template/css/
/template/js/
…
?))))
Насчет второго как бы изначально инициализируется пустой лог, а потом ему ставится игнор. Так что тоже не аргумент. И это не костыли, а логичное решение…
/template/
/template/images/
/template/images/icons/
/template/images/buttons/
/template/images/bg/
/template/css/
/template/js/
…
?))))
Насчет второго как бы изначально инициализируется пустой лог, а потом ему ставится игнор. Так что тоже не аргумент. И это не костыли, а логичное решение…
с моей точки зрения, на этом сайте лучше всего разъяснена разница между гитом и меркуриалом
gitvsmercurial.com/
gitvsmercurial.com/
Примерно подобной статьи я сидел и ждал. Теперь, пожалуй, подвигаюсь немножко и попробую Hg :)
Вот читало бы моё начальство такие статьи и делало выводы, а то мы еще сидим на CVS, хотя когда один работаешь над проектом, то еще ничего.
И всё-таки не пойму, как не на картинках или искусственных демках, а по жизни работает hg/git (организационно, как я понял, они друг от друга мало отличаются).
Вот есть два разработчика (каждый со своим компом), есть тестовый сервер (пускай владелец — тестер), на который бы хотелось автоматом деплоить приложение (ЯП — интерпретируемый, компиляции/сборки не нужно, миграции БД пока за рамками оставим, с файлами бы разобраться) при коммите в ветку test, и боевой сервер (пускай владелец тимлид) — аналогично на него деплоить ветку trunk(production/...). Надо заводить 4 (2 девелоперские машины, тестовый и боевой сервера) локальных репозитория с 4 ветками (dev1, dev2, test, production) в каждом и постоянно их как-то (ручками, хроном, сигналы какие-то друг другу посылают?) синхронизировать друг с другом? Кто выступает инициатором синхронизации — тот, кто делает коммит, требующий синхронизации (то есть распространяет свой коммит на 3 локальных репозитория без их владельцев согласия), или тот, кто хочет свой локальный синхронизировать с остальными (то есть для деплоя на тест нужно будет логиниться на тестовом сервере и опрашивать девелоперские репозитории на предмет изменений, а для деплоя на боевой логиниться на нём и опрашивать тестовый)? Как обеспечивается синхронизация с внешними репозиториями (либы, фреймворки, cms и т. п.)? С SVN всё понятно: закоммитил — всем доступно (если с правами не играть) и об изменениях узнают при очередном чекауте, хуки повесил — отдеплоилось при коммите (с одного заранее известного хоста), а тут? Кричать на весь офис (или в чат) «Я замержил свой патч на тест у себя — синхронизируйтесь со мной и тестируйте» или «О, либа обновилась, все качаем в каждую ветку кроме продакшн и ищем баги дружно!»?
Может кто-нибудь ткнёт пальцем в статью/пост, где описана схема реальной работы (желательно на русском и/или со множеством картинок, а то с залогами всякими английскими проблема)? habrahabr.ru/blogs/Git/106912/ читал, но, как я понял, это не тру-гит вэй, т. к. всё-таки централизованно выходит, да и подробностей маловато. Или я просто несколько опережаю события и в следующих частях всё будет?
Вот есть два разработчика (каждый со своим компом), есть тестовый сервер (пускай владелец — тестер), на который бы хотелось автоматом деплоить приложение (ЯП — интерпретируемый, компиляции/сборки не нужно, миграции БД пока за рамками оставим, с файлами бы разобраться) при коммите в ветку test, и боевой сервер (пускай владелец тимлид) — аналогично на него деплоить ветку trunk(production/...). Надо заводить 4 (2 девелоперские машины, тестовый и боевой сервера) локальных репозитория с 4 ветками (dev1, dev2, test, production) в каждом и постоянно их как-то (ручками, хроном, сигналы какие-то друг другу посылают?) синхронизировать друг с другом? Кто выступает инициатором синхронизации — тот, кто делает коммит, требующий синхронизации (то есть распространяет свой коммит на 3 локальных репозитория без их владельцев согласия), или тот, кто хочет свой локальный синхронизировать с остальными (то есть для деплоя на тест нужно будет логиниться на тестовом сервере и опрашивать девелоперские репозитории на предмет изменений, а для деплоя на боевой логиниться на нём и опрашивать тестовый)? Как обеспечивается синхронизация с внешними репозиториями (либы, фреймворки, cms и т. п.)? С SVN всё понятно: закоммитил — всем доступно (если с правами не играть) и об изменениях узнают при очередном чекауте, хуки повесил — отдеплоилось при коммите (с одного заранее известного хоста), а тут? Кричать на весь офис (или в чат) «Я замержил свой патч на тест у себя — синхронизируйтесь со мной и тестируйте» или «О, либа обновилась, все качаем в каждую ветку кроме продакшн и ищем баги дружно!»?
Может кто-нибудь ткнёт пальцем в статью/пост, где описана схема реальной работы (желательно на русском и/или со множеством картинок, а то с залогами всякими английскими проблема)? habrahabr.ru/blogs/Git/106912/ читал, но, как я понял, это не тру-гит вэй, т. к. всё-таки централизованно выходит, да и подробностей маловато. Или я просто несколько опережаю события и в следующих частях всё будет?
Mercurial — первая система контроля версии, которую я начал использовать. Я полностью доволен.
«И Майк расслабится и поделится косячком с практикантами, и наступит весна, и молодежь из соседнего колледжа сменит пуховики на коротенькие надорванные футболки, и жизнь будет хороша.»
Если этот Джоэль Спольски, автор пособия, наркоман, любящий заглядывать под коротенькие надорванные футболки молодёжи, то хотя бы на русский можно было это не переводить.
Если этот Джоэль Спольски, автор пособия, наркоман, любящий заглядывать под коротенькие надорванные футболки молодёжи, то хотя бы на русский можно было это не переводить.
Перечитывал тут статью и проассоциировал вашего Джейкоба с одноименным героем лоста)
Вот этот момент смутил в статье.
Какая разница — changeset или слепок файлов система хранит? В любом случае если я удаляю функцию из одного файла, вставляю в другой.
Когда нам нужно сделать слияние, Subversion смотрит на обе ревизии — мой измененный код и ваш измененный код — и пытается угадать, как слепить их вместе в один большой страшный бардак. Обычно Subversion это не удается, и получаются длинные списки конфликтов («merge conflicts»), которые на самом деле не конфликты, а просто места, в которых система не смогла разобраться в наших изменениях.
Для сравнения, если мы независимо работали в Mercurial, то система сохраняла серии изменений. Таким образом, когда мы хотим сделать слияние кода, у Mercurial на самом деле гораздо больше информации: система знает, что каждый из нас изменил, и может заново применить эти изменения вместо того, чтобы смотреть на конечный вариант и пытаться угадать, как все это собрать воедино.
Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше.
Так как Mercurial мыслит в терминах наборов изменений, вы можете делать интересные вещи с этими наборами изменений. Вы можете дать попробовать эти изменения другу вместо того, чтобы вносить эти изменения в центральный репозиторий и вынуждать всех ими пользоваться.
Если все это кажется вам немного запутанным — не переживайте. По мере чтения этого пособия все обретет ясный смысл. В данный момент самое главное, что вам нужно знать: из-за того, что Mercurial оперирует наборами изменений, а не ревизиями, слияние кода в Mercurial работает гораздо лучше, чем в Subversion.
Какая разница — changeset или слепок файлов система хранит? В любом случае если я удаляю функцию из одного файла, вставляю в другой.
Спасибо за перевод. В целом статья очень полезна. )
Только вот этот момент смутил:
Вот тут — либо неточность, либо недостаточно раскрыта тема в статье.
Какая разница — changeset или слепок файлов система хранит? Откуда у меркуриала больше информации?
В любом случае если я
в ветке А — удаляю функцию из одного файла, вставляю в другой.
в ветке Б — меняю тело функции на пару строк
Ниодна система контроля версий этого сама не смерджит. Мне кажется ближе к истине вот это programmers.stackexchange.com/a/129926
Только вот этот момент смутил:
Когда нам нужно сделать слияние, Subversion смотрит на обе ревизии — мой измененный код и ваш измененный код — и пытается угадать, как слепить их вместе в один большой страшный бардак. Обычно Subversion это не удается, и получаются длинные списки конфликтов («merge conflicts»), которые на самом деле не конфликты, а просто места, в которых система не смогла разобраться в наших изменениях.
Для сравнения, если мы независимо работали в Mercurial, то система сохраняла серии изменений. Таким образом, когда мы хотим сделать слияние кода, у Mercurial на самом деле гораздо больше информации: система знает, что каждый из нас изменил, и может заново применить эти изменения вместо того, чтобы смотреть на конечный вариант и пытаться угадать, как все это собрать воедино.
Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше.
Так как Mercurial мыслит в терминах наборов изменений, вы можете делать интересные вещи с этими наборами изменений. Вы можете дать попробовать эти изменения другу вместо того, чтобы вносить эти изменения в центральный репозиторий и вынуждать всех ими пользоваться.
Если все это кажется вам немного запутанным — не переживайте. По мере чтения этого пособия все обретет ясный смысл. В данный момент самое главное, что вам нужно знать: из-за того, что Mercurial оперирует наборами изменений, а не ревизиями, слияние кода в Mercurial работает гораздо лучше, чем в Subversion.
Вот тут — либо неточность, либо недостаточно раскрыта тема в статье.
Какая разница — changeset или слепок файлов система хранит? Откуда у меркуриала больше информации?
В любом случае если я
в ветке А — удаляю функцию из одного файла, вставляю в другой.
в ветке Б — меняю тело функции на пару строк
Ниодна система контроля версий этого сама не смерджит. Мне кажется ближе к истине вот это programmers.stackexchange.com/a/129926
Subversion, Mercurial, and Git all track repository-wide snapshots of the project. Calling them versions, revisions, or changesets makes no difference. They are all logically atomic snapshots of a set of files.
The size of your commits makes no difference when it comes to merging. All three systems merge with the standard three-way merge algorithm and the inputs to that algorithm are
greatest common ancestor version
version on one branch
version on other branch
It doesn't matter how the two branch versions were created. You can have used 1000 small commits since the ancestor version, or you can have used 1 commit. All that matters is the final version of the files. (Yes, this is surprising! Yes, lots of DVCS guides get this horribly wrong.)
…
The real reason Git and Mercurial are better at merging than Subversion is a matter of implementation. There are rename conflicts that Subversion simply cannot handle even thought it's clear what the correct answer is. Mercurial and Git handles those easily. But there's no reason why Subversion couldn't handle those as well — being centralized is certainly not the reason.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hg Init: Часть 1. Переобучение для пользователей Subversion