Какой (D)VCS Вы пользуетесь?

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

Git репозиторий как минимум удобно бэкапить куда хочется без всяких костылей, функционал практически прямо из коробки. Ну и вообще странный разработчик который не пользуется ветками для экспериментов и rebase'ами для поддержания проекта в порядке. В svn нормально не работает даже слияние веток.

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

но у меня есть одно правило: никогда не коммитить код, если он не рабочий и проверенный. то есть, любой мой коммит можно собрать и он будет рабочим. не люблю мусор в сорцах.

3 года назад: Какой системой управления версиями вы пользуетесь?

Судя по итогам:

• Доля SVN и копи-фолдер уменьшается с переходом в разрекламированный git.
• Кто пользовался hg, тот им и продолжает пользоваться.

beastie

Всего голосов: 858 , всего проголосовавших: 636

Передайте, плиз, Макскому, что пробел перед запятой лишний

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

Ни разу не было что в прцессе написания какой-то фичи в середине прцесс приходит осознание что вот это место нужно отрефакторить или там вообще баг не связанный с первоначальной задачей?

А чем принципиально ношение репозитория svn на флешке отличается от локального репозитория git, корме того что для svn такой режим не рекомендуется самими авторами svn?

Ну и уже сказано что для git каждый push/fetch - это еще и бэкап

В чем оверкилл?

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

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

эксперименты с кодом не бывают параллельными,

Вообще бывают, но тут важен другой момент - эксперимент может закончится ничем, т.е. в свой же апстрим в итоге ничего из него не попадёт или попадут выборочные изменения. В таком случае в твоей помойке будут ненужные revert-ы.

но у меня есть одно правило: никогда не коммитить код, если он не рабочий и проверенный. то есть, любой мой коммит можно собрать и он будет рабочим. не люблю мусор в сорцах.

Придумываешь себе гемор на ровном месте. Как же тогда быть с бекапами? Код то может долго стабилизироваться и получается тебе нужно бэкапить как сам svn реп, так и свою рабочую копию. C git это всё решается очень просто - { { { временные коммиты в приватную ветку -> push в бэкап(ы) } x N -> rebase } x M -> merge в публичное место }.

Молюсь на Subversion, вынужден иногда использовать Git.

сочуствую

Придумываешь себе гемор на ровном месте. Как же тогда быть с бекапами?

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

репозиторий на флэшке удобен тем, что он в кармане помещается. не вижу проблем с репой на флэшке, если её бэкапить иногда.

оверкилл git-а в том, что он рассчитан исключительно на командную разработку очень объёмного кода. для простых проектов 99% его фич просто не нужны и только добавляют головняков.

Ни разу не было что в прцессе написания какой-то фичи в середине прцесс приходит осознание что вот это место нужно отрефакторить или там вообще баг не связанный с первоначальной задачей?

нет. я сначала думаю, а уже потом, в самом конце, пишу код. весь и сразу. обычно 99% занимает рисование на бумажке или в какой-нить приблуде для UML. а код - это уже фигня, когда архитектура продумана до конца. я иногда даже с документации начинаю писать софт: пока я пишу доки, прописываю детально все API с другими приложениями, я формирую очень чёткую картину того, что в итоге должно получиться и чаще всего все косяки находятся и исправляются ещё на этапе проектирования.

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

О каких головняках речь?

Если один разработчик работает локально в одной ветке, то от svn различий вообще нет. Ровно две команды: add и commit. При этом можно в любой момент можно воспользоваться всеми приимуществами.

PS я реально хочу Вас понять, т.к. мне, возможно, придется скоро переводить несколько человек с svn на DVCS

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

Проблема будет если по какой-то причине фичу придется откатить, а багфикс, естественно, оставить. Чтобы в репозитории не было мусора каждый коммит должен содержать ровно одно логическое изменение.

я сначала думаю, а уже потом, в самом конце, пишу код.

Завидую. В коммерческой коллективной разработке так практически нереально.

Эти многие кроме Git ничего не видели просто.

Я пока не увидел ни одного аргумента в пользу того, чтобы потратить время на изучение hg.

Если один разработчик работает локально в одной ветке, то от svn различий вообще нет.

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

Завидую. В коммерческой коллективной разработке так практически нереально.

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

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

А где-то были аргументы в пользу того, чтобы потратить время на холивары на ЛОРе?

Я выше в треде спрашивал на полном серьезе.

есть одно правило: никогда не коммитить код, если он не рабочий и проверенный

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

Проиллюстрирую наглядно:

$  git | grep push
   push       Update remote refs along with associated objects

$  hg help | grep push 
 push          push changes to the specified destination

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

... просто я начинала программировать, когда ещё не было всей этой беды ... а бэкапить можно в tar, раньше так и жили, никто не жужжал.

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

оверкилл git-а в том, что он рассчитан исключительно на командную разработку очень объёмного кода.

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

Завидую. В коммерческой коллективной разработке так практически нереально.

Это же не от коллектива или коммерциализации проекта зависит, а от объёма работ и проекта. Реально полностью разделять «обдумывание» и реализацию только на небольших объёмах работ - тут узкое звено это мозг человека который в принципе не способен просчитывать с достаточной детализацией много действитй вперёд.

Интересный момент я поймал: http://www.cppmm.net.ru/public/015.png :)

как раз чем больше проект - тем тщательнее надо думать. мелочь можно фигачить сразу, всё равно цена ошибки невелика. в конце концов, не трудно переделать. а вот облажаться в долгосрочном проекте (а если ещё и хардварном!) на сотни миллионов - это малоприятно. и переделать уже не получится.

Это же полнейшая чушь, тебе, как инженеру, должно быть стыдно за такие суждения

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

о бэкапах подумали с самого начала и из этого выросли все остальные фичи связанные с D в DVCS

Это бэкапы выросли из D в DVCS.

Проиллюстрирую наглядно:

Я не понял, что именно вы иллюстрируете? Нужность изучения hg? то что я выбрал git не потому что он мне подходит а из-за понтов?

Я пока вижу разницу в стилистике документации. Кстати, git'овская мне больше импонирует. Не люблю хелпы в духе Капитана Очевидность.

И всё у них так.

Как так?

Во всех обсуждениях на LOR адепты Mercurial'а вызывают у меня такое же недоумение, как фангруппа Столмана у среднестатистического пользователя ПК. Пока единственное продемонстрированное преимущество hg - это ощущение «илитарности» его пользователей.

Для среднестатистического пользователя ПК ты ничем не отличаешься от фанатов Столлмана.

Гит может всё то же, что и меркуриал, даже, может, чуть больше. Но у гит'а юзер-интенфейс через ж (хотя, если начинать с гит'а — это не так заметно).

Т.е. если Вы уже освоили гит и с удобством им пользуетесь, то смысла Вам переходить на Mercurial не вижу (это как переходить с ручной коробки передач на автомат, когда к ручной уже привыкли).

Что же касается новичков (которые пользовались только Subversion или другими не-D VCS):

• в идеальном мире новичку имело бы смысл начинать с Mercurial (не то что там проще, просто интерфейс приятный/логичный);
• но в реальном миру популярность/распиаренность гита и наличие удобных сервисов типа гитхаба могут сыграть.

(По-видимому, littlechris хотел проиллюстрировать разницу. Думал, Вы поймёте с полуслова.)

(Я говорю в общем. На самом деле, между ними есть некоторые отличия в функционале и даже парадигме — и в каких-то случаях они могут сыграть. Но по сути: Mercurial — это изящность интерфейса (хочешь ускориться — жмёшь «газ», хочешь замедлиться — жмёшь «тормоз»); а гит — «ну и зачем оно, если все вокруг ездять с ручной коробкой передач и я сам давно привык».)

эксперименты с кодом не бывают параллельными

Бывают. У меня были случаи, когда репортеру бага нужно дать версию кода с расставленными тут и там printf'ами. Сами они писать код не могут, зато могут его собрать и прогнать на своём железе, собрав выхлоп. А я могу дальше продолжать разработку, не задевая то временное состояние.

Иногда бывает что-то пилишь, а нужно срочно отвлечься на починку бага. Тоже параллельные ветки спасают.

Если в первом случае можно вывернуться, дав инструкции вроде: «выкачай определённую ревизию, да наложи вот этот патч», во втором случае возиться с патчами совсем уж неудобно. Зачем делать рутиные операции, если их может делать за тебя софт?

Меньший размер рабочей копии на стороне клиента

Это наглая ложь. Один чекаут в SVN как правило весит больше чем чекаут + вся история (!) в .git. FreeBSD, например: git - 2.0GiB, svn - 2.7GiB. Из-за уродливейшего устройства базы все операции в svn либо тормозят дисками, либо сетью, тогда как git отвечает мгновенно. Вот и вся киллер фича.

бэкапить можно в tar, раньше так и жили

Уже тогда был RCS, который для маленьких «локальных» репозиториев всё ещё очень удобен.

У webkit, например, размер чекаута в svn на треть меньше git.

Из-за уродливейшего устройства базы все операции в svn либо тормозят дисками, либо сетью, тогда как git отвечает мгновенно

А с этим кто-то спорит?

... я исхожу из простых рациональных соображений. мне не нужна вся история всех коммитов в моём рабочем каталоге. и куча мелких файлов на винте тоже не нужна. я хочу, чтобы репозиторий был максимально компактен,

Subversion в директории с рабочей копией держит все оригинальные копии файлов проекта поштучно и кроме этого сам репозиторий который может быть в разных форматах с, обычно, не пожатыми данными. В Git же все файлы упакованы в несколько пожатых pack-блобов и некоторое кол-во (конфигурируемое) последних изменений лежит поштучно.

Как не трудно заметить, svn в общем создаёт и значительно больше файлов на диске, и даже его данные только в рабочей копии могут быть больше всей аналогичной истории проекта в git (на практике оно почти всегда так и бывает). Рациональности в твоих соображениях нет.

... лежал отдельно от моего рабочего места и чтобы при работе мне не нужно было тащить из него мегабайты.

Положи куда хочется ... откуда у тебя мегабайты в проекте который ты пилишь в одно лицо?

и да, я ненавижу метки коммитов в виде хэша километровой длины. они мне ни о чём не говорят и неудобны при работе с проектом.

Единственная рациональная проблема, хотя и она решаема при желании.

Любое обращение к репозиторию по сети - адовые тормоза

А в гите адово тормозят операци с файловой системой. Хорошо, что я не виндузятник.

А файлы какого размера считаются большими?

Такие, для которых народ применяет всякие git lfs, git media, git annex и т.п.

Конечно, я неправильно выразился, имеются в виду большие сжатые файлы: изображения, видео, архивы и т.п.

Мне вот никогда не приходилось версировать файлы более 50 Мб и git на них не спотыкался.

А он и не будет спотыкаться, просто раздуется размер рабочей копии, и удаление файла в очередной ревизии уже ничего не улучшит

Это бэкапы выросли из D в DVCS.

Речь идёт конкретно про Git, а его дизайн обусловлен в первую очередь именно заботой о целостности репозитория. Да и в общем целостные бэкапы не вытекают просто из DVCS.

... между ними есть некоторые отличия в функционале и даже парадигме ... Но по сути: Mercurial — это изящность интерфейса (хочешь ускориться — жмёшь «газ», хочешь замедлиться — жмёшь «тормоз»)

На самом деле в hg нельзя нажать газ и ускориться, он заточен исключительно под типового пользоваться, который плохо умеет работать даже просто VCS. И как только захочется выжать все соки из (D)VCS для построения оптимальных схем работы с проектом, то костыльность дизайна ртути сразу даёт о себе знать.

И как только захочется выжать все соки из (D)VCS для построения оптимальных схем работы с проектом, то костыльность дизайна ртути сразу даёт о себе знать.

Расскажи об этом подробнее.

Речь идёт конкретно про Git, а его дизайн обусловлен в первую очередь именно заботой о целостности репозитория.

Дизайн Monotone, ты хотел сказать.

Да и в общем целостные бэкапы не вытекают просто из DVCS.

Бэкапы на DVCS настолько же целостны, насколько целостен репозиторий DVCS. Репозиторий на криптохешах (OpenCM, далее везде) целостен автоматически,

как раз чем больше проект - тем тщательнее надо думать. мелочь можно фигачить сразу...

У раздумий есть как минимум два измерения, одно, связанное с размером проекта, зависит от объема архитектуры, а другое - от планируемого объёма вносимых изменений. Произведение этих величин, грубо говоря, даёт ёмкость общих умственных затрат и если она превышает возможности человека, то эту работу становится невозможно сделать за один цикл из отдельных стадий рисования на бумажке и кодинга. Потому, почти всегда в сложных проектах, один подход к снаряду состоит из нескольких циклов доводки кода до кондиции и крайне редко получается сначала всё обдумать и потом разом закодить без пересмотра деталей и доводок. Речь идёт не о количестве ресурса, а на что именно его придётся потратить.

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

Что же касается новичков (которые пользовались только Subversion или другими не-D VCS):

пару лет назад наблюдал целую команду таких «новичков» (на самом деле у всех по десятку лет опыта) перетаскивающих относительно небольшой проект из SVN (до этого был у всех либо SVN либо прости г-ди TFS) в меркуриал. Столько мата я от них не слышал даже когда они разбирали окаменевший говнокод весом в гигабайты (серьезно). При этом вытаскивание оттуда же нескольких заопенсорсенных либ на гитхаб прошло как по маслу.

git

Другого ничего не знаю

перетаскивающих относительно небольшой проект из SVN (до этого был у всех либо SVN либо прости г-ди TFS) в меркуриал. Столько мата я от них не слышал даже когда они разбирали окаменевший говнокод весом в гигабайты (серьезно). При этом вытаскивание оттуда же нескольких заопенсорсенных либ на гитхаб прошло как по маслу.

Научились немножко.

fossil, mercurial, git, cvs (только получение)

Только git, разумеется. Остальное не работает, не нужно и вообще умерло. Ладно там мои личные и рабочие проекты, но я уже лет 5 не видел ни одного нового свободного проекта не на git(hub). Остались только мамонты (ff на hg, freebsd на svn, openbsd на cvs - и смех и грех).

Я пока не увидел ни одного аргумента в пользу того, чтобы потратить время на изучение hg.

Hg имеет очень разумный CLI. У Git CLI кошмарный, хуже сложно придумать. Но если написать себе алиасов, то в целом он даже удобнее (staging area из коробки и т.д.). Поэтому, действительно, в общем случае смысла нет, особенно учитывая, что по разным причинам мерк однозначно и навсегда проиграл гиту в популярности (увы или не увы — другой вопрос).

staging area из коробки и т.д.

Но staging area у git убога до удивления по сравнению с mq или подобными системами для самого git.