насколько продвинута интеграция Mercurial в твой JetBrains (а она там есть)

Там довольно примитивная интеграция mercurial, нет поддержки даже для mercurial queues.

Забавная аргументация

Это вообще-то не аргументация. Как аргументацией не пахло и в твоём смехотворном заявлении. Третьего варианта нету, кстати.

Там довольно примитивная интеграция mercurial, нет поддержки даже для mercurial queues.

Ну это не очень удивительно, у mq не очень-то много аналогов, а у них там наверняка обобщённый интерфейс к SCM. А вот интегрировать со своими task/context вполне могли все SCM.

Есть же git.

Зачем нужен git, когда есть Hg?

Ну как зачем, чтоб были осмысленные срачи. Не в пример этому.

Git — очень хорошая и крутая система, но в некоторых ситуациях я более за Subversion. Например, Subversion никогда не теряет историю, если только не химичить hex-редактором репозиторий на сервере

В git тоже, если есть центральный репозиторий

Это даёт некоторую уверенность, например если некто рукожопый разнесёт и угробит всё, я потом приду и просто верну всё на место.

В твой локальный репозиторий он не придет (если ты не дал ему доступ к своему компу ;), так что ты сможешь даже восстановить главный репозиторий, если его попортят

Git например позволяет удалять ветки (с уникальными патчами; хотя и неохотно).

Что очень легко отменяется, так как при этом стирается только «название головы»

Это не проблема Git'а; проблема в том, что некоторые люди воспринимают слова Линуса о том, что пользователи Subversion дурачьё, буквально.

По-моему, для этой категории людей авторитетом может быть кто угодно, но не Линус

Линус, кстати, только разработчиков svn дурачьём обзывал, если речь про его знаменитую лекцию на Google I/O

народная тропа точно не зарастет

Свою карьеру IT'шника я начинал, как думаю и многие уважаемые посетили ЛОРа, в одной занюханной шараге с быдло кодерами и быдло начальством. Я как и все в конторе быдлокодил в борланд билдере. Не помню с чего все началось, но народ начал обсуждать системы контроля версий и думать что же лучше - RCS или CVS? Помимо кодинга я еще присматривал за серверами линуксовым, так что внедрять систему контроля версий доверили мне, чему я был ужасно рад (какое доверие! :). Внедрение CVS казалось чем то невероятно крутым и прогрессивным! Все было хорошо по началу, но через полгода репозитарием CVS уже ползовались все разработчики и так как они были истинными быдлокодерами то помимо сырцов складывали практически все что у них было. Сервер CVS представлял из себя обычный PC поставленный в серверную комнату, так что шансов у бедняги было не много - место на фс быстро закончилось. Стали разбираться в чем дело то? Вроде просто исходники и немного бинарей. Тут то и выяснилось что системы контроля версий ориентированные на разработчиков не особо парятся про бинарные файлы и тупо хранят бинарник целиком для каждой его ревизии. В общем такой подход нормально работает для небольшой команды, но не масштабируется. Работать с бинарниками CVS так никогда и не научился (впрочем как git и mercurial по сей день, да и надо ли?). Гдето через полтора года появился новый проект - Subversion! Рождение новой звезды, не меньше! Внедрение началось с самых прошаренных - с выпускников МИФИ. Потом появился проект TutoiseSVN и вопросы типа «А как этой херней будут пользоваться нормальные люди?» отпали сами собой. В каждой следующей компании где я работал - с первых дней я ставлю репозитарий subversion и рассылаю svn-book. Я точно знаю что люди так и пользуются этими репозитариями. Однако после шараги я в основном работаю с обычными людьми, которые вообще слабо понимают что такое контроль версий и всегда в таких случаях внедрение хоть самой простой системы - уже серьезный результат. Так что в таких условиях svn куда лучше git или mercurial - просто и понятно даже для секретарши после пары тренингов. А вот в компаниях где серьезные девелоперы трудятся они сами себе ставят mercurial или git - кому что нравится. Я считаю что сравнивать subversion vs git/mecurial - не имеет смысла. Вы опытный разработчик и работаете в сильной команде - внедряйте git/mecurial. Вы работаете в обычном офисе и генерите много бинарных файлов - только svn, только хардкор! :)

Хотя бы ради возможности ребейзнуть ветку.

А если этого не нужно?

Работать с бинарниками CVS так никогда и не научился (впрочем как git и mercurial по сей день

И git, и mercurial умеют работать с бинарниками.

И git, и mercurial умеют работать с бинарниками.

Не сильно разбираюсь в git и mercurial, поэтому поправь, если я не прав.
Mercurial/git хранят всю историю на компе каждого разработчика. Если в проекте есть бинарные файлы, и они часто менялись, то репозиторий сильно распухает. В случае git/marcurial этот распухший репозиторий будет храниться на компе у каждого разработчика, в то время как subversion на компе разработчика будет хранить только последнюю версию.

Да, всё правильно. Где «неумение работать»?

Кстати, до версии 1.6 или 1.7 в рабочей копии SVN хранилось две копии каждого файла, из-за чего рабочая копия SVN могла быть величиной с весь репозиторий hg.

Где «неумение работать»?

Ммм. Вообще-то моя позиция: «для каждой задачи подходит свой инструмент». Я не против git/mercurial, ровно как и subversion, но я категорически за то, чтобы знать и учитывать достоинства и недостатки каждого, и делать выбор для каждой конкретной задачи соответственно.

«неумение работать» - это не ко мне.

Вообще-то моя позиция: «для каждой задачи подходит свой инструмент»

Есть инструменты похуже и получше, применимые к одному и тому же классу задач.

я категорически за то, чтобы знать и учитывать достоинства и недостатки каждого

А для этого их нужно изучать. Чтобы знать о largefiles в Mercurial и GIT_ALTERNATE_OBJECT_DIRECTORIES в git.

Третьего варианта нету, кстати.

Я же писал, что по понятным причинам он вам просто не может прийти в голову.

annulen

guitarist

Git — очень хорошая и крутая система, но в некоторых ситуациях я более за Subversion. Например, Subversion никогда не теряет историю, если только не химичить hex-редактором репозиторий на сервере

В git тоже, если есть центральный репозиторий

Я так понимаю что не совсем (под ц.р. я понимаю gitolite-сервер, есть другие варианты?); например можно сделать git push -f и изменить в общем-то историю на сервере, например убрать часть последних коммитов. Можно ли их восстановить? Всегда ли? Я далеко не эксперт (пока) в git, так что с радостью бы узнал об этом поподробнее.

annulen

guitarist

Это даёт некоторую уверенность, например если некто рукожопый разнесёт и угробит всё, я потом приду и просто верну всё на место.

В твой локальный репозиторий он не придет (если ты не дал ему доступ к своему компу ;), так что ты сможешь даже восстановить главный репозиторий, если его попортят

Не то чтобы я кого-то буду пускать в свой локальный репозиторий, но беда в том, что я сначала сделаю pull, а уже потом обнаружу, что всё пошло по бороде :(

annulen

guitarist

Git например позволяет удалять ветки (с уникальными патчами; хотя и неохотно).

Что очень легко отменяется, так как при этом стирается только «название головы»

Но удаление в Subversion идёт как отдельный commit, там прямо всё как на ладони будет, а для удалённой ветки в Git нужно будет найти безымянную голову и придумать ей название. Например можно вернуться из отпуска и обнаружить такой бардак. Я понимаю, это может звучать нереально, но блин, бывают такие дятлы...

annulen

guitarist

Это не проблема Git'а; проблема в том, что некоторые люди воспринимают слова Линуса о том, что пользователи Subversion дурачьё, буквально.

По-моему, для этой категории людей авторитетом может быть кто угодно, но не Линус

Ну да, скорее это уже на конце испорченного телефона получается. Внедрёж идёт через цепочку людей.

Повторюсь наверное, Git мне очень нравится и я собираюсь пройти его на эксперте (а пока, можно сказать, только поиграл в казуальный вариант), просто я стараюсь подходить к делу более взвешенно.

Хотя бы ради возможности ребейзнуть ветку.

А если этого не нужно?

Ребейзнуть можно (без вероятности FFFFFFUUUUUUUUUUUUUUUU.... от коллег) только грубо говоря локальную ветку, а локальных веток в Subversion не бывает. Соответственно более полный ответ на вопрос был бы «ради возможности вести локальные ветки», IMHO. Ну в общем это по обстоятельствам надо смотреть. Например, где я работаю — все ветки всегда публикуются в центральный репозиторий. Особых отличий от современных версий Subversion при этом в работе нет. Но это не единственный вариант использования.

Например, где я работаю — все ветки всегда публикуются в центральный репозиторий.

У вас не было случаев, когда разработчик случайно отпочковался не от транка, а от ветки куда скидываются все фичи для тестирования на стенде, набил туда полсотни коммитов и потом это дело надо слить обратно в транк?

С svn веселье еще то.

только грубо говоря локальную ветку

Это настолько грубо, что попахивает бабушкиными страшилками.

Я так понимаю что не совсем (под ц.р. я понимаю gitolite-сервер, есть другие варианты?); например можно сделать git push -f и изменить в общем-то историю на сервере, например убрать часть последних коммитов. Можно ли их восстановить?

В gitolite можно запретить делать push -f.

что поделать, если с ветками *настолько* не срослось у svn.

это не замена веткам, учите матчасть.

Так что ты хочешь сказать-то?

богомерзкие IDE умеют в эту приблуду, а православные ылитные инструменты (vim, emacs, notepad, edlin итп.) — не умеют. как так? А если развить тему, можно придти к совсем святотатственному выводу о том, что Православные Ылитные Инструменты не могут заменить IDE(А).

ты сам-то покури, насколько продвинута интеграция Mercurial в твой JetBrains

JetBrains — организация. IDEA и производные — продукт.

Да, интеграция hg в данный момент хреновата по ряду причин. Однако её пилят — пинки в багтрекере не игнорируются. Да и вообще — было время, когда hg4idea был совсем отдельным плагином. А теперь оно лежит в основном дереве.

И я тихо, когда никто не видит, коммичу изменения кусочков кода, над которыми работаю, в свой локальный репозиторий Subversion

Для этого гораздо удобнее fossil.

это не замена веткам, учите матчасть

Ну расскажи же, зачем эта шляпа нужна, если есть нормальные ветки?

богомерзкие IDE умеют в эту приблуду, а православные ылитные инструменты (vim, emacs, notepad, edlin итп.) — не умеют. как так?

Во-первых, мы вроде как про SCM тут говорим.

Во-вторых, не умеют, и что? Я использую vim и hg в комстроке, потому что я хорошо понимаю, что делают оба инструмента, могу полностью задействовать их возможности и не зависеть при этом от какой-то магии IDE. Для тебя критична возможность переключать свои task'и в IDE — пользуйся. Для меня критичны мощь и удобство vim как текстового редактора. Сохранять список открытых файлов в vim тоже можно, переключать ветки из командной строки — легко. Если неймётся, обернуть это в одну команду тоже много ума не надо. Только толку от этого чуть.

Для этого гораздо удобнее fossil

Почему? А то я не уловил преимуществ fossil и veracity, когда читал про них. Даже и пробовать не стал.

Почему? А то я не уловил преимуществ fossil и veracity, когда читал про них. Даже и пробовать не стал.

Компактность: все хранится в одном файле - легко хранить, делать резервные копии, копировать, передавать другим. Часть данных в файле уже сжата, можно даже не компрессировать при передаче. Простота: минимальный набор хорошо документированных простых команд, сама VCS представляет собой всего один статически слинкованный файл без зависимостей - запускай и ешь. Плюс встроенные баг-трекер и вики, веб-морда искаропки (запускается командой fossil ui в любом месте дерева исходников). Для мелких проектов серебряней пули не найдешь. :)

По сравнению с hg всё равно не впечатляет, но спасибо за рассказ.

По сравнению с hg всё равно не впечатляет, но спасибо за рассказ.

Так и не должно, оно для мелочи только.

Так и непонятно, зачем оно даже для мелочи. Как будто hg для мелочи чем-то плох.

Так и непонятно, зачем оно даже для мелочи. Как будто hg для мелочи чем-то плох.

Если он у тебя уже стоит и ты его постоянно юзаешь, то незачем. Но специально его ставить для мелочевки смысла нет. Хранит он не в одном файле, имеет лишние зависимости в лице педона и т. д.

Ну, работать на системе без Python мне как-то не приходилось. Если нужно вкрячить SCM, а поставить hg проблемно, то смысл есть, но как-то это очень редкая ситуация, мне кажется.

зачем эта шляпа нужна

показываю на пальцах:

% svn st
M foo/bar/file1
M foo/bar/qux
M foo/bar/file2
% svn changelist feature1 foo/bar/file1 foo/bar/qux #тут произвольное кол-во файлов 
% svn ci --cl feature1 #вместо svn commit foo/bar/file1 foo/bar/qux

не умеют, и что?

Ну как что. Не умеют Ылитные Редакторы Текста — а богомерзкими считаются IDE.

Если неймётся, обернуть это в одну команду тоже много ума не надо

агада:

Математик проснулся, выглянул в коридор, увидел висящий огнетушитель, воскликнул: «Решение проблемы существует!» - и ушел спать.

Проблема в том, что этого «решения» _почему-то_ никто не видел.

Только толку от этого чуть.

А я говорю, что намного больше, чем «чуть» — очень помогает не терять контекст в голове.

показываю на пальцах

Если ты думал, что откроешь мне этим что-то новое, то спешу тебя разочаровать.

Повторяю: не ощущаю смысла. И писать кипятком от алиаса для группы файлов не намерен. Для подобных вещей в hg есть:

* hg commit --include ... --exclude ... * mq * ветки

Дело в том, что нельзя поощрять разработку в таком ключе, потому что фиксируется непроверенный код. Ревизия в репозиторий уже ушла, но никто не проверял код в том виде, в котором он там зафиксирован. И если ты там поднасрал, то уже никак не исправишь, система-то централизована, приехали. Можешь только вдогонку заслать исправление, но bisect уже поломан, например. А, хотя какой там у вас bisect, ха-ха.

Проблема в том, что этого «решения» _почему-то_ никто не видел

Ты зачем глупый такой? Ты не веришь, что в vim можно сохранять и загружать список открытых буферов? Погугли. Ты не веришь, что vim может переключать ветки? Погугли, он и команды может внешние дёргать, и плугины есть. Ты не веришь, что эти две команды можно сцепить в одну? Так поверь, можно. Просто не нужно это никому, подгонять стиль своей работы под эти рамки.

я говорю, что намного больше, чем «чуть» — очень помогает не терять контекст в голове

И как же это происходит? Вот ты сидишь-сидишь и вдруг — бац! — всё забыл. Глянул на список `svn changelist` — и опять прозрел. Или как?

Если нужно вкрячить SCM, а поставить hg проблемно, то смысл есть, но как-то это очень редкая ситуация, мне кажется.

fossil выше был предложен как раз для редкой ситуации - для сохранения своих фрагментов кода, когда в конторе вообще не используют SCM. Мне показалось, он для этой цели лучше svn'а.

Да уж даже bzr лучше. Наверное.

Но удаление в Subversion идёт как отдельный commit, там прямо всё как на ладони будет, а для удалённой ветки в Git нужно будет найти безымянную голову и придумать ей название.

В твоем-то репозитоии ее никто не удалит, так что запушишь опять, если нужна.

http://whybzrisbetterthanx.github.com/

Я так понимаю что не совсем (под ц.р. я понимаю gitolite-сервер, есть другие варианты?);

Есть gitosis, а вообще лучше сразу использовать систему code review, напимер, Gerrit

например можно сделать git push -f и изменить в общем-то историю на сервере, например убрать часть последних коммитов.

Настраивайте права доступа, чтобы кто попало не мог сделать такую вещь в общей ветке (а лучше чтобы вообще никто не мог)

Можно ли их восстановить? Всегда ли? Я далеко не эксперт (пока) в git, так что с радостью бы узнал об этом поподробнее.

В описанной ситуации мерж локальной и удаленной веток скорее всего не пройдет, а если даже пройдет, его можно отменить.

Не то чтобы я кого-то буду пускать в свой локальный репозиторий, но беда в том, что я сначала сделаю pull, а уже потом обнаружу, что всё пошло по бороде :(

Не используй git pull. Используй git fetch и смотри, что происходит в origin/*. Или просто ограничь доступ дятлам к общим веткам.

Не используй git pull

А еще лучше не используй git вообще.

Не используй git pull. Используй git fetch и смотри, что происходит в origin/*. Или просто ограничь доступ дятлам к общим веткам.

Хорошая мысль, спасибо.

У вас не было случаев, когда разработчик случайно отпочковался не от транка, а от ветки куда скидываются все фичи для тестирования на стенде, набил туда полсотни коммитов и потом это дело надо слить обратно в транк?

С svn веселье еще то.

Бывало что один-два коммита шли не туда, но чтобы пол-сотни — нет. Ну неприятно, конечно, однако поправимо. :)

http://whybzrisbetterthanx.github.com/

Ну если с git или hg сравнивать, то да. Но я-то про svn говорил.

Есть gitosis

В gitosis последние признаки жизнедеятельности датируются 2008 годом. Вместо него есть развивающийся gitolite. С точки зрения управления репозитариями оба продукта идентичны, разве что в gitolite конфиг немного поудобнее.